VIA's Southbridge bug: Latest (pseudo-)patch

VIA's Southbridge bug: Latest (pseudo-)patch

[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).

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
-- 
Axel.Thimm@physik.fu-berlin.de

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Alan Cox]

> 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

VIA politics (was: VIA's Southbridge bug: Latest (pseudo-)patch)

[Axel Thimm]

On Sat, May 19, 2001 at 05:11:30PM +0100, Alan Cox wrote:
> > 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

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 <YipingChen@via.com.tw> 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.

> 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.
-- 
Axel.Thimm@physik.fu-berlin.de

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Ingo Oeser]

On Sat, May 19, 2001 at 05:11:30PM +0100, Alan Cox wrote:
> 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
-- 
To the systems programmer,
users and applications serve only to provide a test load.

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[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.

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

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Gerhard Mack]

> 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

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Udo A. Steinberg]

Gerhard Mack wrote:
> 
> > 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.

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Dan Hollis]

On Mon, 21 May 2001, Udo A. Steinberg wrote:
> 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

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[God]

On Mon, 21 May 2001, Udo A. Steinberg wrote:

> Gerhard Mack wrote:
> > 
> > > 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....

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Alan Cox]

> > 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

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Dan Hollis]

On Mon, 21 May 2001, Gerhard Mack wrote:
> > 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

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[God]

On Mon, 21 May 2001, Gerhard Mack wrote:

> Subject: Re: VIA's Southbridge bug: Latest (pseudo-)patch
> 
> > 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? :)

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Przemyslaw Wegrzyn]

On Sat, 19 May 2001, Axel Thimm wrote:

> 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=- 

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Marc Lehmann]

On Sat, May 19, 2001 at 11:07:21AM +0200, Axel Thimm <Axel.Thimm@physik.fu-berlin.de> wrote:
> 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")

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)

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Jeff Garzik]

Marc Lehmann wrote:
> 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.

-- 
Jeff Garzik      | Disbelief, that's why you fail.
Building 1024    |
MandrakeSoft     |

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Marc Lehmann]

On Fri, Jun 01, 2001 at 11:28:48AM -0400, Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
> 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).

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Adrian Cox]

Marc Lehmann wrote:


> 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.

-- 
Adrian Cox   http://www.humboldt.co.uk/

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Marc Lehmann]

On Sun, Jun 03, 2001 at 11:10:02PM +0100, Adrian Cox <adrian@humboldt.co.uk> wrote:
> > 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 :()

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Dan Hollis]

On Wed, 6 Jun 2001, Marc Lehmann wrote:
> 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

Re: VIA's Southbridge bug: Latest (pseudo-)patch

[Gérard Roudier]

On Sun, 3 Jun 2001, Adrian Cox wrote:

> Marc Lehmann wrote:
> 
> 
> > 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.

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.

RE: VIA's Southbridge bug: Latest (pseudo-)patch

[Khachaturov, Vassilii]

There is such a web page, and it's the .html version of the Hardware-HOWTO
on any LDP mirror.
Some distribution even print it and include with their booklets accompanying
the installation CDs.
Make sure you send case reports about any unsupported crap hardware there...

> -----Original Message-----
> What we need is a web page for listing crap hardware so less 
> people buy
> it.
> 
> 	Gerhard