![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 12:15 [W:0.309 / U:0.220 seconds] ©2003-2008 Jasper Spaans | |||||||||||||