Re: VIA's Southbridge bug: Latest (pseudo-)patch
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Sun, Jun 03, 2001 at 11:10:02PM +0100, Adrian Cox <[EMAIL PROTECTED]> 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 +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Sun, Jun 03, 2001 at 11:10:02PM +0100, Adrian Cox [EMAIL PROTECTED] 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 +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Fri, Jun 01, 2001 at 11:28:48AM -0400, Jeff Garzik <[EMAIL PROTECTED]> 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 +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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 | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Sat, May 19, 2001 at 11:07:21AM +0200, Axel Thimm <[EMAIL PROTECTED]>
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 +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Sat, May 19, 2001 at 11:07:21AM +0200, Axel Thimm [EMAIL PROTECTED]
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 +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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 | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Fri, Jun 01, 2001 at 11:28:48AM -0400, Jeff Garzik [EMAIL PROTECTED] 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 +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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? :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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? :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: VIA's Southbridge bug: Latest (pseudo-)patch
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: VIA's Southbridge bug: Latest (pseudo-)patch
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA politics (was: VIA's Southbridge bug: Latest (pseudo-)patch)
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 <[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.
> 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.
--
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 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). 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
--
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
--
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 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). 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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=- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA politics (was: VIA's Southbridge bug: Latest (pseudo-)patch)
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 [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. 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. -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
