[PATCH] Athlon bug stomper. Pls apply.

[PATCH] Athlon bug stomper. Pls apply.

[VDA]

Hi Linus, Alan,

Since we don't have any negative feedback on Athlon bug
stomper, I think patch could be applied to
arch/i386/kernel/pci-pc.c in mainline kernel.
Diffed against 4.2.9.
BTW, there are similar fixup routines in drivers/pci/quirks.c
Why two .c files for hw related fixes?
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/

--- pci-pc.c.orig       Sun Aug 12 15:54:07 2001
+++ pci-pc.c    Tue Sep 18 16:45:21 2001
@@ -948,6 +948,26 @@
        d->irq = 9;
 }
 
+/* Fixes some oopses on Athlon optimized
+ * fast_copy_page when it uses 'movntq's
+ * instead of 'movq's on Athlon/Duron optimized kernels. 
+ * Bit 7 at offset 0x55 seems to be responsible:
+ * > Device 0 Offset 55 - Debug (RW)
+ * >   Bits 7-0: Reserved (do not program). default = 0
+ * ABIT KT7A 3R BIOS: 0x89 (oopses)
+ * ABIT KT7A YH BIOS: 0x00 (works)
+ */
+static void __init pci_fixup_athlon_bug(struct pci_dev *d)
+{
+       u8 v;
+        pci_read_config_byte(d, 0x55, &v);
+        if(v & 0x80) {
+                printk(KERN_NOTICE "Stomping on Athlon bug.\n");
+                v &= 0x7f; /* clear bit 55.7 */
+                pci_write_config_byte(d, 0x55, v);
+        }
+}
+
 struct pci_fixup pcibios_fixups[] = {
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_82451NX,    pci_fixup_i450nx },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_82454GX,    pci_fixup_i450gx },
@@ -961,6 +981,7 @@
 /* Our bus code shouldnt need this fixup any more. Delete once verified */
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_COMPAQ,   PCI_DEVICE_ID_COMPAQ_6010,      pci_fixup_compaq },
 #endif 
+       { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      PCI_DEVICE_ID_VIA_8363_0,       pci_fixup_athlon_bug },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_UMC,      PCI_DEVICE_ID_UMC_UM8886BF,     pci_fixup_umc_ide },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_SI,       PCI_DEVICE_ID_SI_5513,          pci_fixup_ide_trash },
        { PCI_FIXUP_HEADER,     PCI_ANY_ID,             PCI_ANY_ID,                     pci_fixup_ide_bases },

Re: [PATCH] Athlon bug stomper. Pls apply.

[Alan Cox]

> stomper, I think patch could be applied to
> arch/i386/kernel/pci-pc.c in mainline kernel.
> Diffed against 4.2.9.
> BTW, there are similar fixup routines in drivers/pci/quirks.c

arch/i386/kernel/pci-pc   PC specific fixups

drivers/pci/quirks.c 	Cross platform fixes

Re: [PATCH] Athlon bug stomper. Pls apply.

[Albert D. Cahalan]

Alan Cox writes:
> [somebody]

>> stomper, I think patch could be applied to
>> arch/i386/kernel/pci-pc.c in mainline kernel.
>> Diffed against 4.2.9.
>> BTW, there are similar fixup routines in drivers/pci/quirks.c
>
> arch/i386/kernel/pci-pc   PC specific fixups
> 
> drivers/pci/quirks.c 	Cross platform fixes

memcopy is kind of fundamental you know... sure it can never get
used before the PCI fix-up code gets a chance to run?

Re: [PATCH] Athlon bug stomper. Pls apply.

[Jeff Garzik]

On Tue, 18 Sep 2001, VDA wrote:
> Since we don't have any negative feedback on Athlon bug
> stomper, I think patch could be applied to
> arch/i386/kernel/pci-pc.c in mainline kernel.
> Diffed against 4.2.9.
> BTW, there are similar fixup routines in drivers/pci/quirks.c
> Why two .c files for hw related fixes?

One is limited to x86, one is not.

	Jeff

Re: [PATCH] Athlon bug stomper. Pls apply.

[Liakakis Kostas]

Please consider making it a configurable option. 

My Asus A7V133 runs perfectly well with 55.7=1 and so does at least
another mobo brand that was reported here. If it can work out of the box,
leave it that way. Since this register is undocumented the patch below is
a hack. Sure it works on people hitting the problem but it is still a
hack. As such I don't want to use it if I don't have to.

-K.


On Tue, 18 Sep 2001, VDA wrote:

> Hi Linus, Alan,
> 
> Since we don't have any negative feedback on Athlon bug
> stomper, I think patch could be applied to
> arch/i386/kernel/pci-pc.c in mainline kernel.
> Diffed against 4.2.9.
[patch snipped]

Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[VDA]

Wednesday, September 19, 2001, 12:39:07 AM,
Liakakis Kostas <kostas@skiathos.physics.auth.gr> wrote:

LK> Please consider making it a configurable option. 

LK> My Asus A7V133 runs perfectly well with 55.7=1 and so does at least
LK> another mobo brand that was reported here. If it can work out of the box,
LK> leave it that way. Since this register is undocumented the patch below is
LK> a hack. Sure it works on people hitting the problem but it is still a
LK> hack. As such I don't want to use it if I don't have to.

Look into pci-pc.c amd quirks.c: do you want to make all those
config options too?

Also, do you want people to spend days finding out why their
once stable system with their brand new, faster processor
started to oops, finally giving up and posting about this to lkml?
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Liakakis Kostas]

I am just opposing to be forced to use a fix when a fix isn't really
needed on my setup.


On Wed, 19 Sep 2001, VDA wrote:

> Look into pci-pc.c amd quirks.c: do you want to make all those
> config options too?

I will, and if I find something done not needed I might complain again.

> Also, do you want people to spend days finding out why their
> once stable system with their brand new, faster processor
> started to oops, finally giving up and posting about this to lkml?

I dont suppose it will take more than an hour for somebody to notice that
under the "Optimized for K7" option there is another called "Enable 55.7=0
fix for K7 that oops all over the place"

Please calm down. I never suggested your fix is wrong. It was a long
awaited one indeed. I only suggested that it be applied wherever it needs
to be, not blindly whenever a KT133/A setup is seen.

If you don't agree with my view, just say why, don't go arround mocking me
about it.

-K.

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Thomas Langås]

Liakakis Kostas:
> Please calm down. I never suggested your fix is wrong. It was a long
> awaited one indeed. I only suggested that it be applied wherever it needs
> to be, not blindly whenever a KT133/A setup is seen.

If this should be an optional fix, it should be default enabled, and then
all those who don't want to use the fix, should disable it. But I guess, as
long as it's an option, someone is _bound_ to come naging with their
problems...

-- 
Thomas

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Liakakis Kostas]

Think again.

It seems to fix the stability problem. We don;t know why, but
experimetation shows that those _with_ the problem are relieved. This is
fine! We are happy with it.

We write to a register marked as "don't write" by Via. This is potentialy 
dangerous in ways we don't know yet.


> If this should be an optional fix, it should be default enabled, and then
> all those who don't want to use the fix, should disable it. But I guess, as
> long as it's an option, someone is _bound_ to come naging with their
> problems...

How can you know you need it if it is enabled by default. I see many more
ppl just not being bothered enough to check. 

And then, would you prefer having somebody naging about, say, his
northbirdge melting down after 10mins with K7 optimizations enabled?

-K.

Re: [PATCH] Athlon bug stomper. Pls apply.

[Stefan Smietanowski]

Hi.

>>If this should be an optional fix, it should be default enabled, and then
>>all those who don't want to use the fix, should disable it. But I guess, as
>>long as it's an option, someone is _bound_ to come naging with their
>>problems...
>>
> 
> How can you know you need it if it is enabled by default. I see many more
> ppl just not being bothered enough to check. 


How many cpus did you try on your machine ?

Are you 100% sure the fix isn't needed on your machine?

> And then, would you prefer having somebody naging about, say, his
> northbirdge melting down after 10mins with K7 optimizations enabled?

Sure, I can see the mail already:

"My Northbridge melted. It's never done that before".

// Stefan

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Jan Niehusmann]

On Wed, Sep 19, 2001 at 05:31:36PM +0300, Liakakis Kostas wrote:
> It seems to fix the stability problem. We don;t know why, but
> experimetation shows that those _with_ the problem are relieved. This is
> fine! We are happy with it.
> 
> We write to a register marked as "don't write" by Via. This is potentialy 
> dangerous in ways we don't know yet.

Additionally, look at who tested the 'fix' up to now: Probably only
people who had a problem before. And for all of them, the problem got
fixed. But do we know what happens if we use this 'fix' on a computer
that is not broken? No. Perhaps it breaks when we apply the 'fix'?

OTOH, I think there are only two ways to find out: Either we put the
'fix' into a mainline kernel (linux -pre kernel or -ac kernel should
be enough) as a default and look if somebody starts complaining, or
we convince VIA to tell us what the register in question really does.

Jan

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Liakakis Kostas]

On Wed, 19 Sep 2001, Jan Niehusmann wrote:

> OTOH, I think there are only two ways to find out: Either we put the
> 'fix' into a mainline kernel (linux -pre kernel or -ac kernel should
> be enough) as a default and look if somebody starts complaining, or
> we convince VIA to tell us what the register in question really does.

*nod*

Alan said he could squeeze some info out of VIA. Any news yet?

-K.

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Alan Cox]

> On Wed, 19 Sep 2001, Jan Niehusmann wrote:
> 
> > OTOH, I think there are only two ways to find out: Either we put the
> > 'fix' into a mainline kernel (linux -pre kernel or -ac kernel should
> > be enough) as a default and look if somebody starts complaining, or
> > we convince VIA to tell us what the register in question really does.
> 
> *nod*
> 
> Alan said he could squeeze some info out of VIA. Any news yet?

I've been busy working on other things, and being ill. I've not yet pursued
it with them

Re: Re[2]: [PATCH] VIA bug stomper. Pls apply.

[Aaron Tiensivu]

> I've been busy working on other things, and being ill. I've not yet
pursued
> it with them

A minor nit I have with the patch is that it printk's out "Stomping the
Athlon bug", which in actuality is more likely a VIA bug because the
symptoms don't show up in other Althon based chipsets..

Re: Re[2]: [PATCH] VIA bug stomper. Pls apply.

[Roberto Jung Drebes]

On Wed, 19 Sep 2001, Aaron Tiensivu wrote:

> > I've been busy working on other things, and being ill. I've not yet
> pursued
> > it with them
> 
> A minor nit I have with the patch is that it printk's out "Stomping the
> Athlon bug", which in actuality is more likely a VIA bug because the
> symptoms don't show up in other Althon based chipsets..

Anyone tried changing the CPU of a oopsing system to check if it's the CPU
or the mobo? I have no other athlon/duron or motherboard to try here.

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/

Re: Re[2]: [PATCH] VIA bug stomper. Pls apply.

[Nicholas Knight]

On Wednesday 19 September 2001 04:04 pm, Roberto Jung Drebes wrote:
> On Wed, 19 Sep 2001, Aaron Tiensivu wrote:
> > > I've been busy working on other things, and being ill. I've not yet
> >
> > pursued
> >
> > > it with them
> >
> > A minor nit I have with the patch is that it printk's out "Stomping
> > the Athlon bug", which in actuality is more likely a VIA bug because
> > the symptoms don't show up in other Althon based chipsets..
>
> Anyone tried changing the CPU of a oopsing system to check if it's the
> CPU or the mobo? I have no other athlon/duron or motherboard to try
> here.

I had a SINGLE report of different CPU's doing different things, but 
*most* people aren't swapping different chips into the same motherboard 
very often, so all the people without the problem might have the problem 
when they put in a different CPU, and those with the problem might have 
it go away if they put in a different CPU. I can only assume that this 
BIOS bug is only triggered under certain conditions of the CPU.

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Linus Torvalds]

In article <20010919165503.A16359@gondor.com>,
Jan Niehusmann  <jan@gondor.com> wrote:
>
>Additionally, look at who tested the 'fix' up to now: Probably only
>people who had a problem before. And for all of them, the problem got
>fixed. But do we know what happens if we use this 'fix' on a computer
>that is not broken? No. Perhaps it breaks when we apply the 'fix'?

This is my personal main worry.

The problem with things like these is that people for whom the old code
works fine don't tend to be interested in "fixes" floating around on the
net - whether it is for Athlon chipset problems or for driver bugs or
anything else.

Which means that the "statistical sampling" is very skewed by
self-selection, and anybody who knows anything about statistics knows
that sample selection is _very_ important.

Right now, for example, I'm leaning towards applying the patch, but
quite frankly I'm still not certain.  Getting _some_ kind of information
out of VIA would be really good - even just an ACK from somebody who is
under NDA and can say just "yes, it's safe to clear bit 7 of reg 0x55". 

It is _probably_ an undocumented performance thing, and clearing that
bit may slow something down. But it might also change some behaviour,
and knowing _what_ the behaviour is might be very useful for figuring
out what it is that triggers the problem.

			Linus

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[safemode]

It works fine on the KX133 chipset that is on the Abit KA7 motherboard.  So, 
i for one have not applied the patch. 


On Wednesday 19 September 2001 12:00, Linus Torvalds wrote:
> In article <20010919165503.A16359@gondor.com>,
>
> Jan Niehusmann  <jan@gondor.com> wrote:
> >Additionally, look at who tested the 'fix' up to now: Probably only
> >people who had a problem before. And for all of them, the problem got
> >fixed. But do we know what happens if we use this 'fix' on a computer
> >that is not broken? No. Perhaps it breaks when we apply the 'fix'?
>
> This is my personal main worry.
>
> The problem with things like these is that people for whom the old code
> works fine don't tend to be interested in "fixes" floating around on the
> net - whether it is for Athlon chipset problems or for driver bugs or
> anything else.
>
> Which means that the "statistical sampling" is very skewed by
> self-selection, and anybody who knows anything about statistics knows
> that sample selection is _very_ important.
the only way it'll get a good sampling is to put it in the kernel 
I suggest not adding this to the "athlon" cpu selection code.  Rather make it 
a sub-option like many other drivers have.  That way people can select 
whether they need it or not until we are sure it's totally safe for everyone 
to use it by Via saying so or something.   Just a suggestion, other drivers 
do the same thing, so why not the cpu selection screen for workarounds. 


>
> Right now, for example, I'm leaning towards applying the patch, but
> quite frankly I'm still not certain.  Getting _some_ kind of information
> out of VIA would be really good - even just an ACK from somebody who is
> under NDA and can say just "yes, it's safe to clear bit 7 of reg 0x55".
>

> It is _probably_ an undocumented performance thing, and clearing that
> bit may slow something down. But it might also change some behaviour,
> and knowing _what_ the behaviour is might be very useful for figuring
> out what it is that triggers the problem.
>
> 			Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Athlon bug stomper. Pls apply.

[Stefan Smietanowski]

Hi.



>>Which means that the "statistical sampling" is very skewed by
>>self-selection, and anybody who knows anything about statistics knows
>>that sample selection is _very_ important.
>>
> the only way it'll get a good sampling is to put it in the kernel 
> I suggest not adding this to the "athlon" cpu selection code.  Rather make it 
> a sub-option like many other drivers have.  That way people can select 
> whether they need it or not until we are sure it's totally safe for everyone 
> to use it by Via saying so or something.   Just a suggestion, other drivers 
> do the same thing, so why not the cpu selection screen for workarounds. 

Why not simply add it to the next -pre cycle (if 2.4.10 is nearby), ie 
2.4.11-pre1 has it, it goes through a few revisions of -pre and if it's 
stable enough for mainstream, have it standard for 2.4.11, otherwise 
just drop it, fix it, squash it, or do whatever with it :)

And if 2.4.10 isn't that close, add it to -pre13 and do the same, having 
it permanently in 2.4.10 (or not if it's nuclear).

// Stefan

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Nicholas Knight]

On Wednesday 19 September 2001 10:15 am, safemode wrote:
> It works fine on the KX133 chipset that is on the Abit KA7 motherboard.
>  So, i for one have not applied the patch.

That would be because the bug is specific to the KT133A chipset...

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Marek Mentel]

On Wed, 19 Sep 2001 16:41:45 -0700, Nicholas Knight wrote:

>On Wednesday 19 September 2001 10:15 am, safemode wrote:
>> It works fine on the KX133 chipset that is on the Abit KA7 motherboard.
>>  So, i for one have not applied the patch.
>
>That would be because the bug is specific to the KT133A chipset...

 and KT133E -   which is KT133  made  in 0.18 technology AFAIR
--------------------------------------------------------
 Marek Mentel  mmark@koala.ichpw.zabrze.pl  2:484/3.8          
 INSTITUTE FOR CHEMICAL PROCESSING OF COAL , Zabrze , POLAND
 NOTE: my opinions are strictly my own and not those of my employer

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Dan Hollis]

On Wed, 19 Sep 2001, Linus Torvalds wrote:
> It is _probably_ an undocumented performance thing, and clearing that
> bit may slow something down. But it might also change some behaviour,
> and knowing _what_ the behaviour is might be very useful for figuring
> out what it is that triggers the problem.

AFAIK noone has even tested it yet to see what it does to performance! Eg
it might slow down memory access so that athlon-optimized memcopy is now
slower than non-athlon-optimized memcopy. And if it turns out to be the
case, we might as well just use the non-athlon-optimized memcopy instead
of twiddling undocumented northbridge bits...

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: [PATCH] Athlon bug stomper. Pls apply.

[Arjan van de Ven]

Dan Hollis wrote:
> 
> On Wed, 19 Sep 2001, Linus Torvalds wrote:
> > It is _probably_ an undocumented performance thing, and clearing that
> > bit may slow something down. But it might also change some behaviour,
> > and knowing _what_ the behaviour is might be very useful for figuring
> > out what it is that triggers the problem.
> 
> AFAIK noone has even tested it yet to see what it does to performance! Eg
> it might slow down memory access so that athlon-optimized memcopy is now
> slower than non-athlon-optimized memcopy. And if it turns out to be the
> case, we might as well just use the non-athlon-optimized memcopy instead
> of twiddling undocumented northbridge bits...

Ok but that part is simple:

run

http://www.fenrus.demon.nl/athlon.c

.....

Re: [PATCH] Athlon bug stomper. Pls apply.

[Roberto Jung Drebes]

On Wed, 19 Sep 2001, Arjan van de Ven wrote:

> Ok but that part is simple:
> 
> run
> 
> http://www.fenrus.demon.nl/athlon.c

I will run it tonight, and report the results later. Any recommendation,
like running in single user mode, or something like that?

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/

Re: [PATCH] Athlon bug stomper. Pls apply.

[Arjan van de Ven]

Roberto Jung Drebes wrote:
> 
> On Wed, 19 Sep 2001, Arjan van de Ven wrote:
> 
> > Ok but that part is simple:
> >
> > run
> >
> > http://www.fenrus.demon.nl/athlon.c
> 
> I will run it tonight, and report the results later. Any recommendation,
> like running in single user mode, or something like that?

Nah don't bother, just make sure your machine is mostly idle.

The performance difference between the clasical code and the "fast" 
code should be in the 2x order; running the test a few times
should be a good enough test.

Re: [PATCH] Athlon bug stomper. Pls apply.

[Dan Hollis]

On Wed, 19 Sep 2001, Roberto Jung Drebes wrote:
> On Wed, 19 Sep 2001, Arjan van de Ven wrote:
> > Ok but that part is simple:
> > run
> > http://www.fenrus.demon.nl/athlon.c
> I will run it tonight, and report the results later. Any recommendation,
> like running in single user mode, or something like that?

Run with the "athlon fix" on and with it off, contrast and compare.

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: [PATCH] Athlon bug stomper. Pls apply.

[Ignacio Vazquez-Abrams]

On Wed, 19 Sep 2001, Arjan van de Ven wrote:

> Ok but that part is simple:
>
> run
>
> http://www.fenrus.demon.nl/athlon.c

>From an Athlon 1050/KT133 (middle 3 of 5):

Clear:
warm up run: 16653.33
2.4 non MMX: 10803.33
2.4 MMX fallback: 10576.67
2.4 MMX version: 9824.33
faster_copy: 4416.67
even_faster: 4316.67

Copy:
warm up run: 15268.33
2.4 non MMX: 23765.33
2.4 MMX fallback: 23629.33
2.4 MMX version: 15316.67
faster_copy: 9352.00
even_faster: 9333.33

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: [PATCH] Athlon bug stomper. Pls apply.

[Ignacio Vazquez-Abrams]

On Wed, 19 Sep 2001, Ignacio Vazquez-Abrams wrote:

> From an Athlon 1050/KT133 (middle 3 of 5):
>
> Clear:
> warm up run: 16653.33
> 2.4 non MMX: 10803.33
> 2.4 MMX fallback: 10576.67
> 2.4 MMX version: 9824.33
> faster_copy: 4416.67
> even_faster: 4316.67
>
> Copy:
> warm up run: 15268.33
> 2.4 non MMX: 23765.33
> 2.4 MMX fallback: 23629.33
> 2.4 MMX version: 15316.67
> faster_copy: 9352.00
> even_faster: 9333.33

Please note that the 'faster_copy' under clear is in fact 'faster_clear_page'.
It got messed up in the post-processing of the results.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: [PATCH] Athlon bug stomper. Pls apply.

[Ignacio Vazquez-Abrams]

On Wed, 19 Sep 2001, Ignacio Vazquez-Abrams wrote:

> On Wed, 19 Sep 2001, Ignacio Vazquez-Abrams wrote:
>
> > From an Athlon 1050/KT133 (middle 3 of 5):
> >
> > Clear:
> > warm up run: 16653.33
> > 2.4 non MMX: 10803.33
> > 2.4 MMX fallback: 10576.67
> > 2.4 MMX version: 9824.33
> > faster_copy: 4416.67
> > even_faster: 4316.67
> >
> > Copy:
> > warm up run: 15268.33
> > 2.4 non MMX: 23765.33
> > 2.4 MMX fallback: 23629.33
> > 2.4 MMX version: 15316.67
> > faster_copy: 9352.00
> > even_faster: 9333.33
>
> Please note that the 'faster_copy' under clear is in fact 'faster_clear_page'.
> It got messed up in the post-processing of the results.

After Athlon patch:

clear_page() tests
clear_page function 'warm up run'        took 17860 cycles per page
clear_page function '2.4 non MMX'        took 11805 cycles per page
clear_page function '2.4 MMX fallback'   took 11777 cycles per page
clear_page function '2.4 MMX version'    took 12003 cycles per page
clear_page function 'faster_clear_page'  took 4416 cycles per page
clear_page function 'even_faster_clear'  took 4315 cycles per page

copy_page() tests
copy_page function 'warm up run'         took 14930 cycles per page
copy_page function '2.4 non MMX'         took 23337 cycles per page
copy_page function '2.4 MMX fallback'    took 23314 cycles per page
copy_page function '2.4 MMX version'     took 20293 cycles per page
copy_page function 'faster_copy'         took 9159 cycles per page
copy_page function 'even_faster'         took 9071 cycles per page

This is with 2.4.9-ac12-preempt1 in both cases and niced to -20. Subsequent
runs are very similar.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: [PATCH] Athlon bug stomper. Pls apply.

[safemode]

On Wednesday 19 September 2001 16:40, Ignacio Vazquez-Abrams wrote:
> On Wed, 19 Sep 2001, Ignacio Vazquez-Abrams wrote:
> > On Wed, 19 Sep 2001, Ignacio Vazquez-Abrams wrote:
> > > From an Athlon 1050/KT133 (middle 3 of 5):
> > >
> > > Clear:
> > > warm up run: 16653.33
> > > 2.4 non MMX: 10803.33
> > > 2.4 MMX fallback: 10576.67
> > > 2.4 MMX version: 9824.33
> > > faster_copy: 4416.67
> > > even_faster: 4316.67
> > >
> > > Copy:
> > > warm up run: 15268.33
> > > 2.4 non MMX: 23765.33
> > > 2.4 MMX fallback: 23629.33
> > > 2.4 MMX version: 15316.67
> > > faster_copy: 9352.00
> > > even_faster: 9333.33
> >
> > Please note that the 'faster_copy' under clear is in fact
> > 'faster_clear_page'. It got messed up in the post-processing of the
> > results.
>
> After Athlon patch:
>
> clear_page() tests
> clear_page function 'warm up run'        took 17860 cycles per page
> clear_page function '2.4 non MMX'        took 11805 cycles per page
> clear_page function '2.4 MMX fallback'   took 11777 cycles per page
> clear_page function '2.4 MMX version'    took 12003 cycles per page
> clear_page function 'faster_clear_page'  took 4416 cycles per page
> clear_page function 'even_faster_clear'  took 4315 cycles per page
>
> copy_page() tests
> copy_page function 'warm up run'         took 14930 cycles per page
> copy_page function '2.4 non MMX'         took 23337 cycles per page
> copy_page function '2.4 MMX fallback'    took 23314 cycles per page
> copy_page function '2.4 MMX version'     took 20293 cycles per page
> copy_page function 'faster_copy'         took 9159 cycles per page
> copy_page function 'even_faster'         took 9071 cycles per page
>
> This is with 2.4.9-ac12-preempt1 in both cases and niced to -20. Subsequent
> runs are very similar.

this is with 2.4.9-ac12 non preempt and without the patch on an athlon 850 
k7-2 . niced to -20.  It was compiled with gcc 3.0.2  no CFLAGS

Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $ 
clear_page() tests 
clear_page function 'warm up run'        took 21392 cycles per page
clear_page function '2.4 non MMX'        took 14020 cycles per page
clear_page function '2.4 MMX fallback'   took 14778 cycles per page
clear_page function '2.4 MMX version'    took 15416 cycles per page
clear_page function 'faster_clear_page'  took 4396 cycles per page
clear_page function 'even_faster_clear'  took 4165 cycles per page

copy_page() tests 
copy_page function 'warm up run'         took 19788 cycles per page
copy_page function '2.4 non MMX'         took 23562 cycles per page
copy_page function '2.4 MMX fallback'    took 23174 cycles per page
copy_page function '2.4 MMX version'     took 20422 cycles per page
copy_page function 'faster_copy'         took 10132 cycles per page
copy_page function 'even_faster'         took 9449 cycles per page

Using optimizations with this code actually slows it down for me.  perhaps 
this means something.  When using asm code, perhaps it's better to not use 
any compiler flags in the kernel config.  The patch is still needed of course 
to stop user programs from crashing the system, but maybe in the kernel for 
asm sources you shouldn't try any compiler flags and see if that increases 
performance.  this could all be a gcc 3.x'ism though.  

Re: [PATCH] Athlon bug stomper. Pls apply.

[Brad Pepers]

I've noticed that on my Athalon 1.4GHz system (Asus A7V133), I get results 
quite a bit higher than reported here when running the athalon.c program.  
For example everyone posting seemed to get 4000-5000 cycles per page for the 
clear_page fuctions "faster_clear_page" and "even_faster_clear" while mine is 
in the 6300-6700 range.  Does this indicate I'm missing some BIOS 
optimizations?  Slow memory?  Something else?

-- 
Brad Pepers
brad@linuxcanada.com

Re: [PATCH] Athlon bug stomper. Pls apply.

[Erno Kuusela]

hello,

On Wed, 19 Sep 2001, Brad Pepers wrote:

| I've noticed that on my Athalon 1.4GHz system (Asus A7V133), I get results 
| quite a bit higher than reported here when running the athalon.c program.  
| For example everyone posting seemed to get 4000-5000 cycles per page for the 
| clear_page fuctions "faster_clear_page" and "even_faster_clear" while mine is 
| in the 6300-6700 range.  Does this indicate I'm missing some BIOS 
| optimizations?  Slow memory?  Something else?

you have a faster cpu (but same speed memory) - so more
cycles pass by when doing memory operations.

   -- erno

Re: [PATCH] Athlon bug stomper. Pls apply.

[Vojtech Pavlik]

On Wed, Sep 19, 2001 at 07:55:00PM +0100, Arjan van de Ven wrote:
> Dan Hollis wrote:
> > 
> > On Wed, 19 Sep 2001, Linus Torvalds wrote:
> > > It is _probably_ an undocumented performance thing, and clearing that
> > > bit may slow something down. But it might also change some behaviour,
> > > and knowing _what_ the behaviour is might be very useful for figuring
> > > out what it is that triggers the problem.
> > 
> > AFAIK noone has even tested it yet to see what it does to performance! Eg
> > it might slow down memory access so that athlon-optimized memcopy is now
> > slower than non-athlon-optimized memcopy. And if it turns out to be the
> > case, we might as well just use the non-athlon-optimized memcopy instead
> > of twiddling undocumented northbridge bits...
> 
> Ok but that part is simple:
> 
> run
> 
> http://www.fenrus.demon.nl/athlon.c

Here we go, a TBird 1.1G with KT133 (non-A), normally working with value
89 in reg 55, not exhibiting the bug under any setting.

with 89 (working, default):

Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $ 
clear_page() tests 
clear_page function 'warm up run'        took 20842 cycles per page
clear_page function '2.4 non MMX'        took 13737 cycles per page
clear_page function '2.4 MMX fallback'   took 14071 cycles per page
clear_page function '2.4 MMX version'    took 13269 cycles per page
clear_page function 'faster_clear_page'  took 5485 cycles per page
clear_page function 'even_faster_clear'  took 5611 cycles per page

copy_page() tests 
copy_page function 'warm up run'         took 20049 cycles per page
copy_page function '2.4 non MMX'         took 29783 cycles per page
copy_page function '2.4 MMX fallback'    took 29679 cycles per page
copy_page function '2.4 MMX version'     took 20173 cycles per page
copy_page function 'faster_copy'         took 12641 cycles per page
copy_page function 'even_faster'         took 12443 cycles per page

with 09 (working, set using "setpci -d 1106:0305 55=09"):

Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $ 
clear_page() tests 
clear_page function 'warm up run'        took 20763 cycles per page
clear_page function '2.4 non MMX'        took 13754 cycles per page
clear_page function '2.4 MMX fallback'   took 13771 cycles per page
clear_page function '2.4 MMX version'    took 13340 cycles per page
clear_page function 'faster_clear_page'  took 5578 cycles per page
clear_page function 'even_faster_clear'  took 5774 cycles per page

copy_page() tests 
copy_page function 'warm up run'         took 20415 cycles per page
copy_page function '2.4 non MMX'         took 29629 cycles per page
copy_page function '2.4 MMX fallback'    took 29509 cycles per page
copy_page function '2.4 MMX version'     took 20287 cycles per page
copy_page function 'faster_copy'         took 12626 cycles per page
copy_page function 'even_faster'         took 12587 cycles per page

So there is no noticeable difference. The values for 'even_faster' vary
between 10000 and 13000 between different runs with either setting of
register 55.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] Athlon bug stomper. Pls apply.

[Dan Hollis]

On Wed, 19 Sep 2001, Vojtech Pavlik wrote:
> Here we go, a TBird 1.1G with KT133 (non-A), normally working with value
> 89 in reg 55, not exhibiting the bug under any setting.

But its 133a experiencing the problem?

Anyone tried kt266...

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: [PATCH] Athlon bug stomper. Pls apply.

[Vojtech Pavlik]

On Wed, Sep 19, 2001 at 01:57:10PM -0700, Dan Hollis wrote:
> On Wed, 19 Sep 2001, Vojtech Pavlik wrote:
> > Here we go, a TBird 1.1G with KT133 (non-A), normally working with value
> > 89 in reg 55, not exhibiting the bug under any setting.
> 
> But its 133a experiencing the problem?

Yes, only KT133A's were reported with the problem.

> Anyone tried kt266...
> 
> -Dan
> 
> -- 
> [-] Omae no subete no kichi wa ore no mono da. [-]

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] Athlon bug stomper. Pls apply.

[Luigi Genoni]

On the Athlon 1300 Mhz with the patch but a working bios i get.

please consider uts 200 Mhz FSB.


Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $
clear_page() tests
clear_page function 'warm up run'        took 21709 cycles per page
clear_page function '2.4 non MMX'        took 13974 cycles per page
clear_page function '2.4 MMX fallback'   took 13108 cycles per page
clear_page function '2.4 MMX version'    took 13940 cycles per page
clear_page function 'faster_clear_page'  took 5341 cycles per page
clear_page function 'even_faster_clear'  took 5924 cycles per page

copy_page() tests
copy_page function 'warm up run'         took 20559 cycles per page
copy_page function '2.4 non MMX'         took 27741 cycles per page
copy_page function '2.4 MMX fallback'    took 28340 cycles per page
copy_page function '2.4 MMX version'     took 20802 cycles per page
copy_page function 'faster_copy'         took 11894 cycles per page
copy_page function 'even_faster'         took 12288 cycles per page


On Wed, 19 Sep 2001, Arjan van de Ven wrote:

> Dan Hollis wrote:
> >
> > On Wed, 19 Sep 2001, Linus Torvalds wrote:
> > > It is _probably_ an undocumented performance thing, and clearing that
> > > bit may slow something down. But it might also change some behaviour,
> > > and knowing _what_ the behaviour is might be very useful for figuring
> > > out what it is that triggers the problem.
> >
> > AFAIK noone has even tested it yet to see what it does to performance! Eg
> > it might slow down memory access so that athlon-optimized memcopy is now
> > slower than non-athlon-optimized memcopy. And if it turns out to be the
> > case, we might as well just use the non-athlon-optimized memcopy instead
> > of twiddling undocumented northbridge bits...
>
> Ok but that part is simple:
>
> run
>
> http://www.fenrus.demon.nl/athlon.c
>
> .....
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Roberto Jung Drebes]

On Wed, 19 Sep 2001, Dan Hollis wrote:

> AFAIK noone has even tested it yet to see what it does to performance! Eg
> it might slow down memory access so that athlon-optimized memcopy is now
> slower than non-athlon-optimized memcopy. And if it turns out to be the
> case, we might as well just use the non-athlon-optimized memcopy instead
> of twiddling undocumented northbridge bits...

How can I test it? Can someone point me to a simple program to do it? Then
I could run it over the non-optimized, the optimized in the good bios and
the optimized in the bad bios plus patch to test it.

Altough my system shows the bug, I am not sure if we should add the patch
as the default option right now. Actually, we don´t have a clue if the
only thing this bit is doing is solving the bug or if it is going to be
responsible for an unknown and unnoticed bug that will show up later. Why
rush things up? Can´t we wait a word from VIA and then decide what to
do? What could be done is to put this patch somewhere other than the list
where we can point people that come to lkml with this problem to.

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/

Athlon bug stomper: perf. results

[brian]

On Wed, Sep 19, 2001 at 11:43:48AM -0700, Dan Hollis wrote:
> AFAIK noone has even tested it yet to see what it does to performance! Eg
> it might slow down memory access so that athlon-optimized memcopy is now
> slower than non-athlon-optimized memcopy. And if it turns out to be the
> case, we might as well just use the non-athlon-optimized memcopy instead
> of twiddling undocumented northbridge bits...

Ok. perhaps this will help:

System: AMD Duron 800Mhz Epox 8KAT3+ MB

I power cycled machine between tests:


Linux 2.4.9ac5 *without* althon bug stomper patch:

    oopes to death on boot.


Linux 2.4.9ac5 with athlon bug stomper patch:

Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $ 
clear_page() tests 
clear_page function 'warm up run'        took 19854 cycles per page
clear_page function '2.4 non MMX'        took 11991 cycles per page
clear_page function '2.4 MMX fallback'   took 11857 cycles per page
clear_page function '2.4 MMX version'    took 13666 cycles per page
clear_page function 'faster_clear_page'  took 4853 cycles per page
clear_page function 'even_faster_clear'  took 4819 cycles per page

copy_page() tests 
copy_page function 'warm up run'         took 19638 cycles per page
copy_page function '2.4 non MMX'         took 23855 cycles per page
copy_page function '2.4 MMX fallback'    took 24043 cycles per page
copy_page function '2.4 MMX version'     took 19550 cycles per page
copy_page function 'faster_copy'         took 10909 cycles per page
copy_page function 'even_faster'         took 11333 cycles per page


Linux 2.2.19:

Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $ 
clear_page() tests 
clear_page function 'warm up run'        took 14658 cycles per page
clear_page function '2.4 non MMX'        took 13254 cycles per page
clear_page function '2.4 MMX fallback'   took 13099 cycles per page
clear_page function '2.4 MMX version'    took 13005 cycles per page
clear_page function 'faster_clear_page'  took 4913 cycles per page
clear_page function 'even_faster_clear'  took 4887 cycles per page

copy_page() tests 
copy_page function 'warm up run'         took 19664 cycles per page
copy_page function '2.4 non MMX'         took 26431 cycles per page
copy_page function '2.4 MMX fallback'    took 26432 cycles per page
copy_page function '2.4 MMX version'     took 19537 cycles per page
copy_page function 'faster_copy'         took 11564 cycles per page
copy_page function 'even_faster'         took 11467 cycles per page



-- 
Brian Litzinger <brian@worldcontrol.com>

    Copyright (c) 2000 By Brian Litzinger, All Rights Reserved

Re: Athlon bug stomper: perf. results

[Dan Hollis]

On Wed, 19 Sep 2001 brian@worldcontrol.com wrote:
> Linux 2.4.9ac5 *without* althon bug stomper patch:
>     oopes to death on boot.

And without kernel athlon optimization, please.

It should be clear: run the athlon.c on a kernel WITHOUT athlon kernel
optimization, but with the 'athlon bug stomper patch' on and off.

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: Athlon bug stomper: perf. results

[brian]

On Wed, Sep 19, 2001 at 01:30:36PM -0700, Dan Hollis wrote:
> On Wed, 19 Sep 2001 brian@worldcontrol.com wrote:
> > Linux 2.4.9ac5 *without* althon bug stomper patch:
> >     oopes to death on boot.
> 
> And without kernel athlon optimization, please.
> 
> It should be clear: run the athlon.c on a kernel WITHOUT athlon kernel
> optimization, but with the 'athlon bug stomper patch' on and off.

Did I miss a simple program for turning the bit on and off?

Or do I need to build appropriate kernels?

-- 
Brian Litzinger <brian@worldcontrol.com>

    Copyright (c) 2000 By Brian Litzinger, All Rights Reserved

Re: Athlon bug stomper: perf. results

[Dan Hollis]

On Wed, 19 Sep 2001 brian@worldcontrol.com wrote:
> On Wed, Sep 19, 2001 at 01:30:36PM -0700, Dan Hollis wrote:
> > On Wed, 19 Sep 2001 brian@worldcontrol.com wrote:
> > > Linux 2.4.9ac5 *without* althon bug stomper patch:
> > >     oopes to death on boot.
> > And without kernel athlon optimization, please.
> > It should be clear: run the athlon.c on a kernel WITHOUT athlon kernel
> > optimization, but with the 'athlon bug stomper patch' on and off.
> Did I miss a simple program for turning the bit on and off?

"setpci"

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: [PATCH] Athlon bug stomper. Pls apply.

[Simen Thoresen]

>Dan Hollis wrote:
>> 
>> On Wed, 19 Sep 2001, Linus Torvalds wrote:
>> > It is _probably_ an undocumented performance thing, and clearing that
>> > bit may slow something down. But it might also change some behaviour,
>> > and knowing _what_ the behaviour is might be very useful for figuring
>> > out what it is that triggers the problem.
>> 
>> AFAIK noone has even tested it yet to see what it does to performance! Eg
>> it might slow down memory access so that athlon-optimized memcopy is now
>> slower than non-athlon-optimized memcopy. And if it turns out to be the
>> case, we might as well just use the non-athlon-optimized memcopy instead
>> of twiddling undocumented northbridge bits...
>
>Ok but that part is simple:
>
>run
>
>http://www.fenrus.demon.nl/athlon.c
>

On my non-buggy(*) KT133A board with the 55th register set to 09 I get these results;

Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $
clear_page() tests
clear_page function 'warm up run'        took 21729 cycles per page
clear_page function '2.4 non MMX'        took 13341 cycles per page
clear_page function '2.4 MMX fallback'   took 13346 cycles per page
clear_page function '2.4 MMX version'    took 15574 cycles per page
clear_page function 'faster_clear_page'  took 4965 cycles per page
clear_page function 'even_faster_clear'  took 4884 cycles per page

copy_page() tests
copy_page function 'warm up run'         took 21294 cycles per page
copy_page function '2.4 non MMX'         took 38093 cycles per page
copy_page function '2.4 MMX fallback'    took 38270 cycles per page
copy_page function '2.4 MMX version'     took 21380 cycles per page
copy_page function 'faster_copy'         took 10775 cycles per page
copy_page function 'even_faster'         took 11262 cycles per page

Setting the register to 00
Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $
clear_page() tests
clear_page function 'warm up run'        took 21719 cycles per page
clear_page function '2.4 non MMX'        took 13392 cycles per page
clear_page function '2.4 MMX fallback'   took 13354 cycles per page
clear_page function '2.4 MMX version'    took 15615 cycles per page
clear_page function 'faster_clear_page'  took 4963 cycles per page
clear_page function 'even_faster_clear'  took 4886 cycles per page

copy_page() tests
copy_page function 'warm up run'         took 21033 cycles per page
copy_page function '2.4 non MMX'         took 37879 cycles per page
copy_page function '2.4 MMX fallback'    took 37938 cycles per page
copy_page function '2.4 MMX version'     took 21124 cycles per page
copy_page function 'faster_copy'         took 10717 cycles per page
copy_page function 'even_faster'         took 11130 cycles per page

In my view these are pretty similar.

(*) - Yes, I did report a buggy KT133A Epox 8KTA/3 board, but the board and processor croaked, and my vendor replaced them with an Epox 8KTA/3 Pro board, and I've had no problems with it so far.

Yours,
-Simen
--
Simen Thoresen, Beowulf-cleaner and random artist - close and personal.

Er det ikke rart?
The gnu RART-project on http://valinor.dolphinics.no:1080/~simentt/rart

Re: [PATCH] Athlon bug stomper. Pls apply.

[Dan Hollis]

On Wed, 19 Sep 2001, Simen Thoresen wrote:
> On my non-buggy(*) KT133A board with the 55th register set to 09 I get these results;

AFAIK you want it 89 not 09

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: [PATCH] Athlon bug stomper. Pls apply.

[Simen Thoresen]

>On Wed, 19 Sep 2001, Simen Thoresen wrote:
>> On my non-buggy(*) KT133A board with the 55th register set to 09 I get these results;
>
>AFAIK you want it 89 not 09
>
Why? by default it is '09' on my system, it does not experience any oops-problems, and the spec still reads it to be '00' and 'dont program'.

I'm now applying the patch and rebuilding the kernel to permanently zero it.

Yours,
-S
--
Simen Thoresen, Beowulf-cleaner and random artist - close and personal.

Er det ikke rart?
The gnu RART-project on http://valinor.dolphinics.no:1080/~simentt/rart

Re: [PATCH] Athlon bug stomper. Pls apply.

[Roberto Jung Drebes]

On Wed, 19 Sep 2001, Simen Thoresen wrote:

> Why? by default it is '09' on my system, it does not experience any
> oops-problems, and the spec still reads it to be '00' and 'dont
> program'.
> 
> I'm now applying the patch and rebuilding the kernel to permanently zero it.

The patch is not supposed to set it to 0, only to clear bit 7, so if your
system has it as 0x09, the patch has no effect, since bit 7 is already
cleared.

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/

Re: [PATCH] Athlon bug stomper. Pls apply.

[VDA]

Hello Arjan,
Wednesday, September 19, 2001, 9:55:00 PM, you wrote:
>> AFAIK noone has even tested it yet to see what it does to performance! Eg
>> it might slow down memory access so that athlon-optimized memcopy is now
>> slower than non-athlon-optimized memcopy. And if it turns out to be the
>> case, we might as well just use the non-athlon-optimized memcopy instead
>> of twiddling undocumented northbridge bits...

AvdV> Ok but that part is simple: run
AvdV> http://www.fenrus.demon.nl/athlon.c

Well, this tester is really useful.
Some bugs though:
* fast_copy_page() does fsave instead of frstor
* do we need femms before frstor?
  My PII at work does not even execute femms...
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Pavel Machek]

Hi!

> > It is _probably_ an undocumented performance thing, and clearing that
> > bit may slow something down. But it might also change some behaviour,
> > and knowing _what_ the behaviour is might be very useful for figuring
> > out what it is that triggers the problem.
> 
> AFAIK noone has even tested it yet to see what it does to performance! Eg
> it might slow down memory access so that athlon-optimized memcopy is now
> slower than non-athlon-optimized memcopy. And if it turns out to be the
> case, we might as well just use the non-athlon-optimized memcopy instead
> of twiddling undocumented northbridge bits...

And if someone does optimized copy in userspace, whole machine is dead?

Do you really wnt me to post bugtraq?

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Nicholas Knight]

On Wednesday 19 September 2001 09:00 am, Linus Torvalds wrote:
> In article <20010919165503.A16359@gondor.com>,

>
> Right now, for example, I'm leaning towards applying the patch, but
> quite frankly I'm still not certain.  Getting _some_ kind of
> information out of VIA would be really good - even just an ACK from
> somebody who is under NDA and can say just "yes, it's safe to clear bit
> 7 of reg 0x55".
>

Is there an way someone could find out what Windows, possibly with VIA's 
4-in-1 drivers, do with this bit? And for that matter, what the test 
program that tests it regardless of kernel optimizations does in Windows, 
if it can be ported?

Re: [PATCH] Athlon bug stomper. Pls apply.

[Stefan Smietanowski]

Hi.

> Is there an way someone could find out what Windows, possibly with VIA's 
> 4-in-1 drivers, do with this bit? And for that matter, what the test 
> program that tests it regardless of kernel optimizations does in Windows, 
> if it can be ported?

Windows XP standard doesn't touch it. This MSI K7T Turbo BIOS Rev 2.9 
(latest) which has a KT133A sets it to 0x8D as default though. No, not 
89. One unexplained reboot on the machine (it's not mine) though. I'll 
try setting the bit to 0 though and see if it remains stable. I'll wait 
for another unexplained reboot first though.

// Stefan

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Liakakis Kostas]

On Wed, 19 Sep 2001, Nicholas Knight wrote:

> Is there an way someone could find out what Windows, possibly with VIA's 
> 4-in-1 drivers, do with this bit? And for that matter, what the test 
> program that tests it regardless of kernel optimizations does in Windows, 
> if it can be ported?

Win2k, Via4132. They leave it alone ax 0x89. Asus A7V133, Athlon TB 1.4-C

-K.

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Luigi Genoni]

On Wed, 19 Sep 2001, Jan Niehusmann wrote:

> On Wed, Sep 19, 2001 at 05:31:36PM +0300, Liakakis Kostas wrote:
> > It seems to fix the stability problem. We don;t know why, but
> > experimetation shows that those _with_ the problem are relieved. This is
> > fine! We are happy with it.
> >
> > We write to a register marked as "don't write" by Via. This is potentialy
> > dangerous in ways we don't know yet.
>
> Additionally, look at who tested the 'fix' up to now: Probably only
> people who had a problem before. And for all of them, the problem got
> fixed. But do we know what happens if we use this 'fix' on a computer
> that is not broken? No. Perhaps it breaks when we apply the 'fix'?
No, it won't break.  I tried this patch on an Athlon 1300 Mhz 200 FSB,
that has worked with athlon optimizzed kernels without any problems, and
it still works. I did this just for curiosity, and i was
avoiding to post a long series of it works for me too, since I have just
abit MBs, and before the patch was out I just putted a working bios on
every MB.  Anyway I tried the patch on working Athlon.

And let's try to get VIA to tell us what is going on....

bests
Luigi

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Tom Diehl]

On Wed, 19 Sep 2001, Liakakis Kostas wrote:

>
> I am just opposing to be forced to use a fix when a fix isn't really
> needed on my setup.

If it causes no performance hit I do not see the problem. Since I have
not seen all of this thread I have to ask what is/are the downsides to
blindly enabling this? What are the real concerns? If the concern is
just to keep your machine "factory fresh" do you have anything that says
this is not just a screw up on the bios writers part? Look at all of the
known and documented BIOS bugs there are.

> On Wed, 19 Sep 2001, VDA wrote:
>
> > Look into pci-pc.c amd quirks.c: do you want to make all those
> > config options too?
>
> I will, and if I find something done not needed I might complain again.

You are free to modify things to your preferences. I think the real point
is to fix it for the largest possible audience. Making it a compile option
IMO serves no real benefit and has some potential rather large downsides.
People like to fiddle. If someone turns it off and does not know what they
are doing the next thing you know is they are complaining here about something
that they should not be playing with anyway.

> > Also, do you want people to spend days finding out why their
> > once stable system with their brand new, faster processor
> > started to oops, finally giving up and posting about this to lkml?
>
> I don't suppose it will take more than an hour for somebody to notice that
> under the "Optimized for K7" option there is another called "Enable 55.7=0
> fix for K7 that oops all over the place"

Depends on the skill set that person possesses. some people will find it
some will not. Murphy definitely will be at work here.

Enjoy,

-- 
......Tom		BLAME: The Secret To Success is Knowing who
tdiehl@rogueind.com	to Blame for Your Failures.

Re: [PATCH] Athlon bug stomper. Pls apply.

[Jan Niehusmann]

On Tue, Sep 18, 2001 at 05:51:48PM +0300, VDA wrote:
> Since we don't have any negative feedback on Athlon bug
> stomper, I think patch could be applied to
> arch/i386/kernel/pci-pc.c in mainline kernel.

BTW, just for the statistics: On the Duron 600 machine, for which
I reported the athlon bug, the fix does not work. Register 0x55 has
a default value of 0x81, but setting it to 0x01 (as the fix does)
doesn't solve the problem, athlon optimised 2.4.9 kernels still fail
to run. 

But, OTOH, the computer in question regulary oopses on 2.4.0-test7 which
didn't have the athlon optimises page copy routine at all, so it may be
just a case of faulty hardware :-(

Jan

Re: [PATCH] Athlon bug stomper. Pls apply.

[bill davidsen]

In article <20010924013328.A29582@gondor.com> jan@gondor.com wrote:
| On Tue, Sep 18, 2001 at 05:51:48PM +0300, VDA wrote:
| > Since we don't have any negative feedback on Athlon bug
| > stomper, I think patch could be applied to
| > arch/i386/kernel/pci-pc.c in mainline kernel.
| 
| BTW, just for the statistics: On the Duron 600 machine, for which
| I reported the athlon bug, the fix does not work. Register 0x55 has
| a default value of 0x81, but setting it to 0x01 (as the fix does)
| doesn't solve the problem, athlon optimised 2.4.9 kernels still fail
| to run. 

  I don't consider "doesn't fix the problem" a negative report in this
case. If the system worked without the patch and failed with, that would
be very negative.

| But, OTOH, the computer in question regulary oopses on 2.4.0-test7 which
| didn't have the athlon optimises page copy routine at all, so it may be
| just a case of faulty hardware :-(

  I've been cursing getting an Athlon, because some applications I got
as rpms didn't work. With the patch they do, and I have to assume that
the code notes an Athlon and tries to use whatever caused the kernel to
oops. Fortunately these are development software I'm evaluating for
someone, and I let them know what was happening before they offered it
to the public.

-- 
bill davidsen <davidsen@tmr.com>
 "If I were a diplomat, in the best case I'd go hungry.  In the worst
  case, people would die."
		-- Robert Lipe

Re: [PATCH] Athlon bug stomper. Pls apply.

[Petr Vandrovec]

On 19 Sep 01 at 19:55, Arjan van de Ven wrote:
> 
> Ok but that part is simple:
> 
> run
> 
> http://www.fenrus.demon.nl/athlon.c

Small question - is it OK that 'faster_copy' is faster than
'even_faster'? By only few percents, but... It is dual cpu Tyan,
with two AMD MP 1.2MHz, with 1022:700C AMD hostbridge. I'll
check KT133 at home if I'll remember...
                                        Thanks,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                

Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $ 
clear_page() tests 
clear_page function 'warm up run'    took 13967 cycles per page
clear_page function '2.4 non MMX'    took 9298 cycles per page
clear_page function '2.4 MMX fallback'   took 9284 cycles per page
clear_page function '2.4 MMX version'    took 8508 cycles per page
clear_page function 'faster_clear_page'  took 4016 cycles per page
clear_page function 'even_faster_clear'  took 3916 cycles per page

copy_page() tests 
copy_page function 'warm up run'     took 15118 cycles per page
copy_page function '2.4 non MMX'     took 17002 cycles per page
copy_page function '2.4 MMX fallback'    took 16978 cycles per page
copy_page function '2.4 MMX version'     took 15163 cycles per page
copy_page function 'faster_copy'     took 8569 cycles per page
copy_page function 'even_faster'     took 8805 cycles per page

Re: [PATCH] Athlon bug stomper. Pls apply.

[Arjan van de Ven]

On Wed, Sep 19, 2001 at 09:15:17PM +0000, Petr Vandrovec wrote:
> On 19 Sep 01 at 19:55, Arjan van de Ven wrote:
> > 
> > Ok but that part is simple:
> > 
> > run
> > 
> > http://www.fenrus.demon.nl/athlon.c
> 
> Small question - is it OK that 'faster_copy' is faster than
> 'even_faster'? 

Yeah; both are "new style" with a minor variation, "even_faster" is
basically my test victim, and faster_ is the "last known good" one.

> clear_page function '2.4 MMX version'    took 8508 cycles per page
> clear_page function 'faster_clear_page'  took 4016 cycles per page
> clear_page function 'even_faster_clear'  took 3916 cycles per page

Yup, > 2x improvement, that's expected

> 
> copy_page() tests 
> copy_page function '2.4 MMX version'     took 15163 cycles per page
> copy_page function 'faster_copy'     took 8569 cycles per page
> copy_page function 'even_faster'     took 8805 cycles per page

same here

If it were only 5%, I would vote for disabling the optimisation given the
number of problems; however it's 2x _and_ you can trigger the bug as normal 
user from userspace too... so we need to fix the hardware/bios.

Greetings,
   Arjan van de Ven

Re: [PATCH] Athlon bug stomper. Pls apply.

[Dan Hollis]

On Wed, 19 Sep 2001, Arjan van de Ven wrote:
> If it were only 5%, I would vote for disabling the optimisation given the
> number of problems; however it's 2x _and_ you can trigger the bug as normal
> user from userspace too... so we need to fix the hardware/bios.

But we really dont know what the hell that bit is doing. It might trigger
some other obscure bugs and make things a real mess.

Until we get some answer from VIA its IMHO a bad idea to start twiddling
this bit willy-nilly on all machines.

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: [PATCH] Athlon bug stomper. Pls apply.

[Arjan van de Ven]

On Wed, Sep 19, 2001 at 12:51:07PM -0700, Dan Hollis wrote:
> On Wed, 19 Sep 2001, Arjan van de Ven wrote:
> > If it were only 5%, I would vote for disabling the optimisation given the
> > number of problems; however it's 2x _and_ you can trigger the bug as normal
> > user from userspace too... so we need to fix the hardware/bios.
> 
> But we really dont know what the hell that bit is doing. It might trigger
> some other obscure bugs and make things a real mess.
> 
> Until we get some answer from VIA its IMHO a bad idea to start twiddling
> this bit willy-nilly on all machines.

no argument from me there...

Re: [PATCH] Athlon bug stomper. Pls apply.

[Eric W. Biederman]

Dan Hollis <goemon@anime.net> writes:

> On Wed, 19 Sep 2001, Arjan van de Ven wrote:
> > If it were only 5%, I would vote for disabling the optimisation given the
> > number of problems; however it's 2x _and_ you can trigger the bug as normal
> > user from userspace too... so we need to fix the hardware/bios.
> 
> But we really dont know what the hell that bit is doing. It might trigger
> some other obscure bugs and make things a real mess.
> 
> Until we get some answer from VIA its IMHO a bad idea to start twiddling
> this bit willy-nilly on all machines.

That is the only way we can get information.  We can twiddle this bit and
run memory performance tests on machines that aren't affected and
other stress tests on machines that are affected and see if we can see
if stability is impacted.

Additionaly the motherboards could be instrumented, and we could see
if there are any timing differences.

Of course VIA looking at what they have done and what that bit is
supposed to be is easiest as they have the schemantics of those
chips.  But there is not reason to be limited to just that approach.

Eric

Re: [PATCH] Athlon bug stomper. Pls apply.

[Dan Hollis]

On 19 Sep 2001, Eric W. Biederman wrote:
> Of course VIA looking at what they have done and what that bit is
> supposed to be is easiest as they have the schemantics of those
> chips.  But there is not reason to be limited to just that approach.

Testing it is ok, its rolling the "patch" into production kernels that im
most concerned about.

What happens if the bit happens to fiddle with motherboard voltages and
you end up destroying peoples hardware...

Until we have a straight answer what the hell this bit does, its a very
bad idea to put it into *production kernel*.

We definitely need more data points too. So far we dont have any athlon.c
data for kt133a with the bit on and off, only kt133.

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: [PATCH] Athlon bug stomper. Pls apply.

[John Alvord]

On Wed, 19 Sep 2001 15:13:55 -0700 (PDT), Dan Hollis
<goemon@anime.net> wrote:

>On 19 Sep 2001, Eric W. Biederman wrote:
>> Of course VIA looking at what they have done and what that bit is
>> supposed to be is easiest as they have the schemantics of those
>> chips.  But there is not reason to be limited to just that approach.
>
>Testing it is ok, its rolling the "patch" into production kernels that im
>most concerned about.
>
>What happens if the bit happens to fiddle with motherboard voltages and
>you end up destroying peoples hardware...
>
>Until we have a straight answer what the hell this bit does, its a very
>bad idea to put it into *production kernel*.

Of course the BIOS versions made exactly that change...

john

Re: [PATCH] Athlon bug stomper. Pls apply.

[Dan Hollis]

On Wed, 19 Sep 2001, John Alvord wrote:
> >Until we have a straight answer what the hell this bit does, its a very
> >bad idea to put it into *production kernel*.
> Of course the BIOS versions made exactly that change...

1) We dont know if all "fixed" BIOS versions do it
2) We dont know if all motherboards do it
3) We dont have enough data points to determine if this is a "real fix" yet.
4) We dont know if they do it under all circumstances
   (eg do they read SPD and set it in some situations and not others)
   It may even be CPU rev specific.

IMHO its *FAR* too premature to be rolling this into production kernels
based on the scant evidence we have so far.

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: [PATCH] Athlon bug stomper. Pls apply.

[Daniel T. Chen]

Agreed. Neither my KT133 (Asus A7V bios 1007) nor my KT133A (MSI
K7T-Limited bios 2.8) exhibit the OOPS on boot problem. (For the record,
both have 1 256 pc133 Infineon and 2 128 pc133 Infineons, 1GHz T-bird
[stepping 02].)

---
Dan Chen                 crimsun@email.unc.edu
GPG key: www.cs.unc.edu/~chenda/pubkey.gpg.asc

On Wed, 19 Sep 2001, Dan Hollis wrote:

> 1) We dont know if all "fixed" BIOS versions do it
> 2) We dont know if all motherboards do it
> 3) We dont have enough data points to determine if this is a "real fix" yet.
> 4) We dont know if they do it under all circumstances
>    (eg do they read SPD and set it in some situations and not others)
>    It may even be CPU rev specific.
> 
> IMHO its *FAR* too premature to be rolling this into production kernels
> based on the scant evidence we have so far.
> 
> -Dan

Re: [PATCH] Athlon bug stomper. Pls apply.

[Roberto Jung Drebes]

On Wed, 19 Sep 2001, Dan Hollis wrote:

> We definitely need more data points too. So far we dont have any athlon.c
> data for kt133a with the bit on and off, only kt133.

My system is a kt133a, that show the bug. I have run a hundred tests,
first in a Athlon optimized kernel with the patch (55.7=0) then with a non
optimized kernel (55.7=1).

Here are some typical results:

K7 optimized:
Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $ 
clear_page() tests 
clear_page function 'warm up run'        took 19862 cycles per page
clear_page function '2.4 non MMX'        took 12296 cycles per page
clear_page function '2.4 MMX fallback'   took 12068 cycles per page
clear_page function '2.4 MMX version'    took 14936 cycles per page
clear_page function 'faster_clear_page'  took 4393 cycles per page
clear_page function 'even_faster_clear'  took 4362 cycles per page

copy_page() tests 
copy_page function 'warm up run'         took 22513 cycles per page
copy_page function '2.4 non MMX'         took 26280 cycles per page
copy_page function '2.4 MMX fallback'    took 26275 cycles per page
copy_page function '2.4 MMX version'     took 22537 cycles per page
copy_page function 'faster_copy'         took 10983 cycles per page
copy_page function 'even_faster'         took 11122 cycles per page

and here without:
Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $ 
clear_page() tests 
clear_page function 'warm up run'        took 12871 cycles per page
clear_page function '2.4 non MMX'        took 12325 cycles per page
clear_page function '2.4 MMX fallback'   took 12586 cycles per page
clear_page function '2.4 MMX version'    took 12021 cycles per page
clear_page function 'faster_clear_page'  took 4401 cycles per page
clear_page function 'even_faster_clear'  took 4370 cycles per page

copy_page() tests 
copy_page function 'warm up run'         took 19568 cycles per page
copy_page function '2.4 non MMX'         took 25353 cycles per page
copy_page function '2.4 MMX fallback'    took 25316 cycles per page
copy_page function '2.4 MMX version'     took 19541 cycles per page
copy_page function 'faster_copy'         took 11052 cycles per page
copy_page function 'even_faster'         took 10785 cycles per page

I thought that when I run the program in the non-optimized kernel with
55.7=1, the program was supposed to crash the system, but it doesn't seem
to do. Isn't the program the K7 optimized fast_copy_page()? Weird.

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/

Re: [PATCH] Athlon bug stomper. Pls apply.

[bill davidsen]

In article <Pine.LNX.4.30.0109191249130.26700-100000@anime.net> you write:
| On Wed, 19 Sep 2001, Arjan van de Ven wrote:
| > If it were only 5%, I would vote for disabling the optimisation given the
| > number of problems; however it's 2x _and_ you can trigger the bug as normal
| > user from userspace too... so we need to fix the hardware/bios.
| 
| But we really dont know what the hell that bit is doing. It might trigger
| some other obscure bugs and make things a real mess.
| 
| Until we get some answer from VIA its IMHO a bad idea to start twiddling
| this bit willy-nilly on all machines.

We know one thing it's doing, keeping user programs from causing errors.
If the error didn't occur in user mode I would be more careful, but
having been shown that it does, I will use the fix. Since the older BIOS
versions set it the other way, I'm willing to assume it's safe and move
forward.

-- 
bill davidsen <davidsen@tmr.com>
 "If I were a diplomat, in the best case I'd go hungry.  In the worst
  case, people would die."
		-- Robert Lipe

Re: [PATCH] Athlon bug stomper. Pls apply.

[Dan Hollis]

On Fri, 21 Sep 2001, bill davidsen wrote:
> We know one thing it's doing, keeping user programs from causing errors.
> If the error didn't occur in user mode I would be more careful, but
> having been shown that it does, I will use the fix. Since the older BIOS
> versions set it the other way, I'm willing to assume it's safe and move
> forward.

VIA's own KT133A chipset drivers dont seem to fiddle the bit though...
On other VIA drivers eg MVP3 etc they DO fiddle bits.

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: [PATCH] Athlon bug stomper. Pls apply.

[Vojtech Pavlik]

On Wed, Sep 19, 2001 at 09:15:17PM +0000, Petr Vandrovec wrote:
> On 19 Sep 01 at 19:55, Arjan van de Ven wrote:
> > 
> > Ok but that part is simple:
> > 
> > run
> > 
> > http://www.fenrus.demon.nl/athlon.c
> 
> Small question - is it OK that 'faster_copy' is faster than
> 'even_faster'? By only few percents, but... It is dual cpu Tyan,
> with two AMD MP 1.2MHz, with 1022:700C AMD hostbridge. I'll
> check KT133 at home if I'll remember...

Same here. In a quite number of cases, even_faster is actually slower.
Not always, though. I suspect the measurement is not really exact.

>                                         Thanks,
>                                                 Petr Vandrovec
>                                                 vandrove@vc.cvut.cz
>                                                 
> 
> Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $ 
> clear_page() tests 
> clear_page function 'warm up run'    took 13967 cycles per page
> clear_page function '2.4 non MMX'    took 9298 cycles per page
> clear_page function '2.4 MMX fallback'   took 9284 cycles per page
> clear_page function '2.4 MMX version'    took 8508 cycles per page
> clear_page function 'faster_clear_page'  took 4016 cycles per page
> clear_page function 'even_faster_clear'  took 3916 cycles per page
> 
> copy_page() tests 
> copy_page function 'warm up run'     took 15118 cycles per page
> copy_page function '2.4 non MMX'     took 17002 cycles per page
> copy_page function '2.4 MMX fallback'    took 16978 cycles per page
> copy_page function '2.4 MMX version'     took 15163 cycles per page
> copy_page function 'faster_copy'     took 8569 cycles per page
> copy_page function 'even_faster'     took 8805 cycles per page
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Vojtech Pavlik
SuSE Labs

RE: [PATCH] Athlon bug stomper. Pls apply.

[Leif Sawyer]

Dan Hollis continues the line with..
> On Wed, 19 Sep 2001, John Alvord wrote:
> > >Until we have a straight answer what the hell this bit 
> does, its a very
> > >bad idea to put it into *production kernel*.
> > Of course the BIOS versions made exactly that change...
> 
> 1) We dont know if all "fixed" BIOS versions do it
> 2) We dont know if all motherboards do it
> 3) We dont have enough data points to determine if this is a 
> "real fix" yet.
> 4) We dont know if they do it under all circumstances
>    (eg do they read SPD and set it in some situations and not others)
>    It may even be CPU rev specific.
> 
> IMHO its *FAR* too premature to be rolling this into 
> production kernels
> based on the scant evidence we have so far.
> 

You all realize that this ranting about 'not for production kernels' is
a waste of time and bandwidth, right?

Make it a compile time option.  Simple, Elegant, and you can
choose to try it or not.  

Of course, now that this can of worms is open, the debate will
range on whether it's default is Enabled or Disabled.

Sheesh.

(i'd enclose an updated patch, but I deleted the original posting.)

Re: [PATCH] Athlon bug stomper. Pls apply.

[Petr Vandrovec]

On 19 Sep 01 at 15:13, Dan Hollis wrote:
> On 19 Sep 2001, Eric W. Biederman wrote:
> > Of course VIA looking at what they have done and what that bit is
> > supposed to be is easiest as they have the schemantics of those
> > chips.  But there is not reason to be limited to just that approach.

Well, I want to add some confusion into this thread...
 
> We definitely need more data points too. So far we dont have any athlon.c
> data for kt133a with the bit on and off, only kt133.

... I have at home Asus A7V (with KT133, non A), it has register 0x55
set to 0x89 and I thought that it works fine. I modified athlon.c
so that it fills buffer with random data on start, and then it compares
results of copy_page. And after about 10th run with 0x89 promise
driver told me that func:13 (not 14...) is not supported and all HDDs
became inaccessible. After reboot portion of /usr/include/bits (and 
few other) was overwritten with 0xFF... I was not able to recreate 
this problem after that crash (but I did not tried too hard, as I have
important data on my hdds, and all hdds attached to promise were
affected, not only one which was 'active' before crash (I was doing
compilation & logged outputs on secondary master, but primary master
was corrupted...)

After fsck, reinstalling libc6-dev and apache-doc, I started playing
with 0x55 bits and found that bits 0x80 and 0x01 have no effect on
performance, but CLEARING bit 0x08 increases my motherboard performace
by 1% (I'm getting very consistent results, they vary around +-10 cycles,
with 12200 cycles with 0x08 and 12060 with 0x00 in register 0x55).

So I personally will apply this patch even on my KT133... And just
for completness, kernel 2.4.9-ac10 (with AMD opts), Athlon 1GHz, two
singlesided 128MB DIMMs, interleaving enabled (disabling slows down
K7 copy page system by 4%).
                                            Best regards,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz