Jani Forssell wrote:
>
> We first reported disk corruption with a VIA KT133A based board (Abit KT7A)
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=100651892331843&w=2
> http://marc.theaimsgroup.com/?l=linux-kernel&m=100669782329815&w=2
>
> ...
> It turned out that the main culprit was the NIC that was attached to PCI
> slot
> 4. Moving it to slot 3 resolved the disk corruption as well as the oopses
> that
> occured. Other PCI slots to avoid for the NIC were 5 and 6. Slot 4 & 6
> shares
> an IRQ with the VIA USB controller, but I did try disabling it from the BIOS
> but it didn't help (lspci didn't show the device after it had been
> disabled).
> Slot 5 shares and IRQ with the Highpoint controller.
>
> Finally, we tested that it works with an Adaptec 2940UW SCSI card in PCI
> slot
> 1 and the NIC in PCI slot 3.
>
> More details on request. Does anyone have any idea what causes this?
My BP6's [hpt366] had similar sustained I/O lockup issues, especially
when running a RAID stripe. From the v1.01 BP6 manual:
...
PCI slots 4 and 5 use the same bus master control signal.
PCI slot 3 shares IRQ signals with the HPT366 IDE controller
(Ultra ATA/66). The driver for the HPT 366 IDE controller
supports IRQ sharing with other PCI devices. But if you
install a PCI card that doesn t allow IRQ sharing with other
devices into PCI slot 3, you may encounter some problems.
Furthermore, if your Operating System doesn t allow peripheral
devices to share IRQ signals with each other--Windows NT for
example, you can t install a PCI card into PCI slot 3.
...
Of course, I didn't read this until much later.
rgds,
tim.
-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 23 2002 - 21:00:31 EST