[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: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Petr Vandrovec]

On 19 Sep 01 at 17:31, 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.

Just small question - you are saying that your KT133A works fine with
0x89... Two questions then - Do you have more than 256MB in your box?
And second one: Do you have one, two, or three memory modules installed
on the board? 

If your answer is <=256MB, one module, no surprise then, as AFAIK nobody 
with such config suffers from the problem. But checking also number of 
memory modules looks more like black magic that anything else. 
Hopefully VIA will answer...
                                            Thanks,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                

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

[Liakakis Kostas]

On Wed, 19 Sep 2001, Petr Vandrovec wrote:

> 
> Just small question - you are saying that your KT133A works fine with
> 0x89... Two questions then - Do you have more than 256MB in your box?

Right.

> And second one: Do you have one, two, or three memory modules installed
> on the board? 

3 x 256MB double sided, unbuffered and -guess what- no-name.

> If your answer is <=256MB, one module, no surprise then, as AFAIK nobody 
> with such config suffers from the problem. But checking also number of 
> memory modules looks more like black magic that anything else. 
> Hopefully VIA will answer...

/me hopes too.

-K.

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

[Gergely Tamas]

Hi!

 > If your answer is <=256MB, one module, no surprise then, as AFAIK nobody
 > with such config suffers from the problem. But checking also number of
 > memory modules looks more like black magic that anything else.
 > Hopefully VIA will answer...

Not exactly. I can report about two different machines - my home one, and
one here at workplace - which hit this bug. Linux even does not start on
them with 3R. Both of them have got 256 Mb, one module. This fix helps for
both of them.

Gergely

ps: ABIT KT7A, Duron 750MHz, 256Mb (one module)

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

[Luigi Genoni]

3R was not working for me too, 3C is well working, actually.

Luigi
On Wed, 19 Sep 2001, Gergely Tamas wrote:

> Hi!
>
>  > If your answer is <=256MB, one module, no surprise then, as AFAIK nobody
>  > with such config suffers from the problem. But checking also number of
>  > memory modules looks more like black magic that anything else.
>  > Hopefully VIA will answer...
>
> Not exactly. I can report about two different machines - my home one, and
> one here at workplace - which hit this bug. Linux even does not start on
> them with 3R. Both of them have got 256 Mb, one module. This fix helps for
> both of them.
>
> Gergely
>
> ps: ABIT KT7A, Duron 750MHz, 256Mb (one module)
>
> -
> 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.

[Luigi Genoni]

On Wed, 19 Sep 2001, Petr Vandrovec wrote:

> On 19 Sep 01 at 17:31, 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.
>
> Just small question - you are saying that your KT133A works fine with
> 0x89... Two questions then - Do you have more than 256MB in your box?
> And second one: Do you have one, two, or three memory modules installed
> on the board?
>
> If your answer is <=256MB, one module, no surprise then, as AFAIK nobody
> with such config suffers from the problem. But checking also number of
> memory modules looks more like black magic that anything else.
> Hopefully VIA will answer...
Just to add a curiosity. Abit KT7A MBs do not accept all 256 MB modules.
with some of them they do see just 128 MB, and anyway systems are stable,
but of course systems managers get unhappy.
This should be because of modules density...

OK, this was OT but maybe some of you had this experience.

Luigi

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

[john slee]

On Thu, Sep 20, 2001 at 01:07:29AM +0200, Luigi Genoni wrote:
> Just to add a curiosity. Abit KT7A MBs do not accept all 256 MB modules.
> with some of them they do see just 128 MB, and anyway systems are stable,
> but of course systems managers get unhappy.
> This should be because of modules density...

bx chipsets have a limitation of 128mb per bank for non-registered dimms
afaik.  ie. 256mb dimms that are two-bank will work as expected, and
256mb dimms that are one-bank will be seen as 128mb.  generally two-bank
256mb dimms have chips on both sides of the module, whereas one-bank
jobbies have it on one side...  found this out the expensive way :-(

of course this isnt relevant to abit kt7 boards but it does sound very
similar.

j.

-- 
R N G G   "Well, there it goes again... And we just sit 
 I G G G   here without opposable thumbs." -- gary larson

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

[Gábor Lénárt]

BTW ...
When I switched to Duron with a new (well, it was my friend's) motherboard
(according to lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)),
I can't boot Linux anymore since it stucked around partiotion checking (sorry
I don't remember, but I can check on the next week). It was kernel 2.2.19.
2.4.x works without any problem, the last kernel I've checked (and using now)
is 2.4.9. Is it the same problem?


On Wed, Sep 19, 2001 at 04:59:09PM +0000, Petr Vandrovec wrote:
> On 19 Sep 01 at 17:31, 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.
> 
> Just small question - you are saying that your KT133A works fine with
> 0x89... Two questions then - Do you have more than 256MB in your box?
> And second one: Do you have one, two, or three memory modules installed
> on the board? 
> 
> If your answer is <=256MB, one module, no surprise then, as AFAIK nobody 
> with such config suffers from the problem. But checking also number of 
> memory modules looks more like black magic that anything else. 
> Hopefully VIA will answer...
>                                             Thanks,
>                                                 Petr Vandrovec
>                                                 vandrove@vc.cvut.cz
>                                                 
> -
> 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/

-- 
 --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]---------[ lgb@lgb.hu ]--
 U have 8 bit comp or chip of them and it's unused or to be sold? Call me!
 -------[ +36 30 2270823 ]------> LGB <-----[ Linux/UNIX/8bit 4ever ]-----

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

[Petr Vandrovec]

On 19 Sep 01 at 11:43, 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...

No, we cannot. On boxes which do not work with athlon optimized kernels
any user can execute athlon's fast_page_copy from userspace, causing
corruption on completely unrelated pages, eventually leading to
kernel crash... So you cannot allow untrusted users on such machine.
                                                Best regards,
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz