Hello, On 01/30/2010 04:37 AM, Robert Hancock wrote: > On 01/29/2010 10:13 AM, Ulli.Brennenstuhl wrote: >> After deactivating every single bios option that somehow optimizes the >> pci bus the problem seems to be gone. After some more testing I could >> narrow the problem down to the option "PCI Master 0 WS Write", which >> controls if requests to the pci bus are executed immediately (with zero >> wait states) or if every write request will be delayed by one wait state. >> >> Obviously this reduces the performance. I didn't perform tests but the >> resync speed of the raid dropped from ~ 28mb/s to ~ 17mb/s. >> >> I hope this also solves the problems for other people and it would be >> interesting if any change to the driver would allow to reenable the "PCI >> Master 0 WS Write" option. > > I don't imagine there's anything the driver's likely to be able to do to > avoid it. That sounds like a definite chipset bug. The PCI interface on > older VIA chipsets was pretty notorious for them. Sil3112/3114 are now virtually the only controllers with occassional and unresolved data corruption issues. The other one was sata_via with ATAPI devices which got a possible fix recently (it needed a delay or flush during command issue or CDB leaked into write buffer). Given that these sil chips are used very widely and the relatively low frequency and certain traits like putting two controllers on the bus triggers the problem more easily and this fiddling with PCI bus option resolves it, it's conceivable that signal tx/rx quality of sil3112/4 is borderline in certain cases which usually doesn't show up but causes problem when there also are other weaknesses in the bus (heavy loading, bus controller not having exactly the best signal quality and so on. It would be great if there's some knob we can turn in the controller PCI config space but I really have no idea whatsoever. :-( Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
