Messages in this thread | | | Date | Fri, 18 Jan 2002 16:35:48 -0800 | From | Tim Moore <> | Subject | Re: VIA KT133 & HPT 370 IDE disk corruption |
| |
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/
| |