It seems Søren Schmidt wrote: > > Does this mean that if you dont have the ATA drivers in the kernel then > > you wont get the fix ? As the bug occurs under high PCI loads then this > > can potentially affect people with large amounts of PCI activity on > > SCSI drives too surely ? Granted I've never seen it happen, but it still > > bothers me that it might... > > As far as I'm able to tell, the problem can appear with any PCI device > that can generate enough PCI traffic for the bug to appear, or > at least my tests points in that direction. However I dont have > any SCSI equipment here so I cant tell if that can trigger the > problem...
Hmm, just flipped through some of my notes on this, to be precise I can *not* say that any PCI device can cause this problem, all cases I have has the 686b device as part of the equation, so what we need to show is that there is a problem (or not) when not using the 686b part at all (ie no ATA channels, no VIA sound, no USB traffic and possbily more I've forgotten the 686b handles). If corruption can still appear the fix is "generic". Mind you the fix VIA originally brought out was just to cope with data corruption when using a SB live! and the onboard ATA channels simultaniously. Intensive testing then revealed that the problem could also appear without the SBlive! in the mix, but only banging on the ATA channels (a simple 'dd' between two fast disks one on each channel reveals the bug within seconds). I then did alot of testing using various means of generating lots of PCI traffic, but I can only say from the results I saved that the corruption appeared when the 686b was involved, I dont have any significant data that shows that high PCI loads without the 686b involved fails/works. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
