VIA's Southbridge bug: Latest (pseudo-)patch
This are the latest suggestions for handling the VIA Southbridge bug as derived from the hardware site www.au-ja.de (Many thanks to doelf).
Could a linux kernel specialist review and form this pseudo-patch to a real kernel patch? Given the "old" patch found in 2.4.4 I could have written the part of setting the PCI registers, but I am totally in the dark as to how to identify EPOX Mobos and derive their BIOS ID.
Here comes the pseudo-patch:
if( KT133A || KT133 || KX133 ) {
if( Mainboard=="Epox 8KTA-3(+)" && BIOS>="8kt31417" )
return 0; /* EPOX already fixed it their way. */
#ifdef NEW_PATCH
Offset 76: Set bit5=0 and bit4=1 ("every PCI master grand")
#else /* this is already part of 2.4.4 */
Offset 70: Set bit1=0 ("PCI Delay Transaction = 0") Offset 70: Set bit2=0 ("PCI Master Read Caching = 0") Offset 75: Set bit0-4 ("0 <= PCI Latency <= 32")
#endif
}
History (condensed version, more found in [1]):
- When doelf and his colleagues found the Southbridge bug, they already worked on a solution, which was adopted by most BIOS updates (but not EPOX) and also found its way in 2.4.3-ac7. This patch helped in the majority of the buggy boards, but still left some cases unresolved.
- VIA released their own patch ten days ago which tries to solve the Bug (viapfd100.exe and the latest 4in1 driver). Not only is this patch only for Windows and undocumented, but it also only applies if the running box has a Soundblaster card.
- Someone analysed the patch and found the changed PCI settings so that the patch could be implemented also for systems without a Soundblaster card (see [1]). This is the NEW_PATCH outlined above. This seems to be working (all related hardware sites which had discovered the bug are content now), so it would be nice to have it in the kernel and test it from within linux.
[1] latest english information on the VIA Southbridge bug:
http://www.au-ja.de/review-kt133a-1-en.html
Signature · 1 line
[email protected]
Quoted 2 lines
This are the latest suggestions for handling the VIA Southbridge bug as derived from the hardware site www.au-ja.de (Many thanks to doelf).
I'd rather people left this except for the obvious fixed that were done for non VIA northbridge combinations until 2.5. 2.4 is not an appropriate place to play with possibly disk corrupting PCI hacks without documentation.
What is pathetic is that VIA have yet to place anything in the public domain giving correct workarounds. People are picking at BIOSes praying to spot all the changes (which may not be in the PCI registers even) because a vendor hasn't got the decency to admit they screwed up and then to issue proper fixes
If it had been a manufacturer in most respectable areas of business they'd be recalling and reissuing components, and paying for the end resllers to notify each customer
Alan
Quoted 2 lines · Axel Thimm
This are the latest suggestions for handling the VIA Southbridge bug as derived from the hardware site www.au-ja.de (Many thanks to doelf).
Sorry - little off-topic. I can't find the clean answer anywhere. I use KT7A-RAID, with one disc connected to HTP370, and the other to standard on-board controller.
I've seen comments saying that the bug causes possible corruption of large files being copied between disks on different IDE channels. Does it hit the situation when I'm coping files between the disk on, say, ide0 and the one connected to HPT370 ?
I can't see any article saying what is this bug _in_details_ :(
-=Czaj-nick=-
VIA politics (was: VIA's Southbridge bug: Latest (pseudo-)patch)
In reply to Axel ThimmQuoted 7 lines · Alan Cox
Quoted 2 lines
This are the latest suggestions for handling the VIA Southbridge bug as derived from the hardware site www.au-ja.de (Many thanks to doelf).
I'd rather people left this except for the obvious fixed that were done for non VIA northbridge combinations until 2.5. 2.4 is not an appropriate place to play with possibly disk corrupting PCI hacks without documentation.
Quoted 5 lines
What is pathetic is that VIA have yet to place anything in the public domain giving correct workarounds. People are picking at BIOSes praying to spot all the changes (which may not be in the PCI registers even) because a vendor hasn't got the decency to admit they screwed up and then to issue proper fixes
these are my feelings, too. But I try to be an optimist - this is the reason for the extended Cc: list, maybe it might trigger some change of those politics. Note that Yiping Chen <[email protected]> had contacted this list a few weeks ago to ask how to contribute drivers to Linux, indicating perhaps a first step towards VIA going public domain.
Placing more documentation in the public domain would also help Linux construct the right pirq routing tables, which is also a showstopper for certain KT133A setups.
Quoted 3 lines
If it had been a manufacturer in most respectable areas of business they'd be recalling and reissuing components, and paying for the end resllers to notify each customer
Let's hope VIA will indeed change politics. Either the bug is not fixable and VIA should recall, or the bug/fix should be cleanly documented. Currently VIA is hoping to survive this fiasco by not drawing too much attention ("it was the SB"), but this may become a boomerang (I for my part will try to have the motherboard replaced after having been haunted for the last 6 weeks).
At the very end there are us, the user, who would not want to wait for 2.5 (speak 2.6 for the common user ...). Of course Linux is not to blame, but it is indeed a big user community hit by this.
Regards, Axel.
Signature · 1 line
[email protected]
Quoted 3 lines · Alan Cox
If it had been a manufacturer in most respectable areas of business they'd be recalling and reissuing components, and paying for the end resllers to notify each customer
This is consumer hardware. Consumer products are optimized for a good buzzword count per $ ratio. Everything else is secondary.
Producing cheap stuff has its price. And being so smart an buing cheapest available has the same price. QA and recalling are expensive as hell. That's why cheap products usally have this quality tradeoff.
Most consumers don't like to pay for quality.
Germany has learned this lesson and thus "Made in Germany" doesn't mean anything for certain products anymore :-(
Regards
Ingo Oeser
Signature · 2 lines
To the systems programmer, users and applications serve only to provide a test load.
Quoted 6 lines
Quoted 3 lines
If it had been a manufacturer in most respectable areas of business they'd be recalling and reissuing components, and paying for the end resllers to notify each customer
This is consumer hardware. Consumer products are optimized for a good buzzword count per $ ratio. Everything else is secondary.
Its what I would describe as lack of enforcement by trading standards bodies, and I suspect what the US would call 'insufficient class action lawsuits'
Alan
Quoted 2 lines
Its what I would describe as lack of enforcement by trading standards bodies, and I suspect what the US would call 'insufficient class action lawsuits'
What we need is a web page for listing crap hardware so less people buy it.
Gerhard
--
Gerhard Mack
<>< As a computer I find your faith in technology amusing.
Quoted 6 lines · Gerhard Mack
Quoted 3 lines
Its what I would describe as lack of enforcement by trading standards bodies, and I suspect what the US would call 'insufficient class action lawsuits'
What we need is a web page for listing crap hardware so less people buy it.
Not just crap hardware, but also vendors who refuse to release proper material required for writing drivers. NVidia springs to my mind.
-Udo.
Quoted 2 lines · Udo A. Steinberg
Not just crap hardware, but also vendors who refuse to release proper material required for writing drivers. NVidia springs to my mind.
This would be a browser-busting webpage, the page would be so long...
-Dan
Quoted 11 lines · Udo A. Steinberg
Quoted 6 lines · Gerhard Mack
Quoted 3 lines
Its what I would describe as lack of enforcement by trading standards bodies, and I suspect what the US would call 'insufficient class action lawsuits'
What we need is a web page for listing crap hardware so less people buy it.
Not just crap hardware, but also vendors who refuse to release proper material required for writing drivers. NVidia springs to my mind.
Not that the kernel list is the best place to bring this up, but NVIDIA would NOT be on that list. They are by far one of the best companies out there providing support for their cards. I bought my GF2 for exactly that reason too....
Quoted 7 lines
Quoted 3 lines
Not just crap hardware, but also vendors who refuse to release proper material required for writing drivers. NVidia springs to my mind.
Not that the kernel list is the best place to bring this up, but NVIDIA would NOT be on that list. They are by far one of the best companies out there providing support for their cards. I bought my GF2 for exactly that reason too....
Sure. I spent much happy time telling people to report bugs to nvidia because their closed drivers mean that only nvidia can debug all the crashes people see with them loaded - at least some of which dont occur without the modules
I wouldnt put them on the list though. Nvidia hardware seems to work, and they are being quite honest and up front with their proprietary drivers being exactly that
Quoted 4 lines · Gerhard Mack
Quoted 2 lines
Its what I would describe as lack of enforcement by trading standards bodies, and I suspect what the US would call 'insufficient class action lawsuits'
What we need is a web page for listing crap hardware so less people buy it.
And then get sued by the manufacturers so that they can keep running their scams of selling broken shit hardware to the public.
-Dan
Quoted 7 lines · Gerhard Mack
Subject: Re: VIA's Southbridge bug: Latest (pseudo-)patch
Quoted 2 lines
Its what I would describe as lack of enforcement by trading standards bodies, and I suspect what the US would call 'insufficient class action lawsuits'
What we need is a web page for listing crap hardware so less people buy it.
There _is_ a list of unsupported hardware. But I don't really think one should look down that route rather, I agree with Alan (lawsuits).
I'm holding off
saying anything for now to via as someone mentioned one of their developers was posting on here not to long ago about the problem... I'll admit lately I've been reading my mail with the del key, but from the messages I have read related to the via problem, I have not heard anything more about it. Are they fixing it or ignoring it? I know for windows there is an official bios patch, and some other patch. But
.. well.. what about linux? :)
Quoted 7 lines · Axel Thimm
if( KT133A || KT133 || KX133 ) {
if( Mainboard=="Epox 8KTA-3(+)" && BIOS>="8kt31417" )
return 0; /* EPOX already fixed it their way. */
#ifdefNEW_PATCH
Offset 76: Set bit5=0 and bit4=1 ("every PCI master grand")
#else /* this is already part of 2.4.4 */
Offset 70: Set bit1=0 ("PCI Delay Transaction = 0")
one thing I found out using triel and error is that setting "PCI Delay Transaction" to enabled causes data corruption on WRITE to my ide drives connected to an Promise Ultra 100 PCI controlelr (I didn't get any corruption on the devices connected to the via ide interface, presumably because my bios already had the right fix).
So, while the every pci master grant setting apperently fixes the internal via ide interface corruption the PCI Delay Transaction option also must be buggy (or my promise controller is) and causes data corruption at least with an additional promise ultra 100.
board: asus cuv4x-d (Apollo MVP3 AGP + via686b southbridge)
Signature · 7 lines
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [email protected] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|Quoted 10 lines · Marc Lehmann
one thing I found out using triel and error is that setting "PCI Delay Transaction" to enabled causes data corruption on WRITE to my ide drives connected to an Promise Ultra 100 PCI controlelr (I didn't get any corruption on the devices connected to the via ide interface, presumably because my bios already had the right fix).
So, while the every pci master grant setting apperently fixes the internal via ide interface corruption the PCI Delay Transaction option also must be buggy (or my promise controller is) and causes data corruption at least with an additional promise ultra 100.
I do not mean to point fingers, but don't assume Via is at fault here. Once you get into the area of flushing data (or not flushing, which is what delayed txn would imply), it is entirely possible that the driver simply does not support what occurs when the PCI Delay Txn option is set.
Signature · 3 lines
Jeff Garzik | Disbelief, that's why you fail. Building 1024 | MandrakeSoft |
Quoted 4 lines · Jeff Garzik
Once you get into the area of flushing data (or not flushing, which is what delayed txn would imply), it is entirely possible that the driver simply does not support what occurs when the PCI Delay Txn option is set.
Aren't PCI delayed transaction supposed to be handled by the pci master (e.g. my northbridge), not by the (software) driver for my pdc(?) I would also be surprised if my pdc actually used that feature, not to speak of the fact that the promise + harddisk worked fine in another computer (the data corruption was easily detectable, one couldn't even write 500megs without altered bytes).
Signature · 7 lines
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [email protected] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|Quoted 6 lines · Marc Lehmann
Aren't PCI delayed transaction supposed to be handled by the pci master (e.g. my northbridge), not by the (software) driver for my pdc(?) I would also be surprised if my pdc actually used that feature, not to speak of the fact that the promise + harddisk worked fine in another computer (the data corruption was easily detectable, one couldn't even write 500megs without altered bytes).
Wrong way round. You're right that the pci master is supposed to handle delayed transactions, but during data transfer the pdc is the pci master and the northbridge is the PCI target.
Signature · 1 line
Adrian Cox http://www.humboldt.co.uk/
Quoted 11 lines · Adrian Cox
Quoted 6 lines · Marc Lehmann
Aren't PCI delayed transaction supposed to be handled by the pci master (e.g. my northbridge), not by the (software) driver for my pdc(?) I would also be surprised if my pdc actually used that feature, not to speak of the fact that the promise + harddisk worked fine in another computer (the data corruption was easily detectable, one couldn't even write 500megs without altered bytes).
Quoted 3 lines
Wrong way round. You're right that the pci master is supposed to handle delayed transactions, but during data transfer the pdc is the pci master and the northbridge is the PCI target.
Wrong in my opinion, at least as it is worded. :)
PCI delayed transactions are not a PCI master issue at all, for the reason it is not possible for a PCI master to distiguish between a transaction which is delayed by the target and a simple retry requested by the target.
Btw, a PCI master that is unable to properly retry a transaction (could the transaction be handled by the target as a delayed transaction on not) would not allow a system to work for a long time. I would expect system breakage within seconds in such situation.
Gérard.
Quoted 7 lines · Adrian Cox
Quoted 2 lines
data corruption was easily detectable, one couldn't even write 500megs without altered bytes).
Wrong way round. You're right that the pci master is supposed to handle delayed transactions, but during data transfer the pdc is the pci master and the northbridge is the PCI target.
Ok, so it could be the promise controller (the controller, however, worked for a long time in another board with no via chipset and pci delayed transactions enabled, so I guess it is not only dependnet on the promise controller).
and this means that there is no automatic workaround, since not all systems seem to have this problem.
I *do* hate silent data corruption :()
Signature · 7 lines
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [email protected] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|Quoted 1 line · Marc Lehmann
I *do* hate silent data corruption :()
An "integrity loopback" device would certainly detect silent corruption.
Eg a loopback which CRC's all blocks read/written and screams loudly if the CRC fails.
-Dan