* RE: [PATCH] Athlon bug stomper. Pls apply.
@ 2001-09-19 23:33 Leif Sawyer
0 siblings, 0 replies; 44+ messages in thread
From: Leif Sawyer @ 2001-09-19 23:33 UTC (permalink / raw)
To: linux-kernel
Cc: Eric W. Biederman, Arjan van de Ven, Petr Vandrovec, Dan Hollis,
John Alvord
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.)
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
@ 2001-09-20 13:08 Petr Vandrovec
0 siblings, 0 replies; 44+ messages in thread
From: Petr Vandrovec @ 2001-09-20 13:08 UTC (permalink / raw)
To: Dan Hollis; +Cc: Arjan van de Ven, linux-kernel, ebiederm
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
@ 2001-09-19 21:15 Petr Vandrovec
2001-09-19 19:21 ` Arjan van de Ven
2001-09-19 20:52 ` Vojtech Pavlik
0 siblings, 2 replies; 44+ messages in thread
From: Petr Vandrovec @ 2001-09-19 21:15 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 21:15 Petr Vandrovec
@ 2001-09-19 19:21 ` Arjan van de Ven
2001-09-19 19:51 ` Dan Hollis
2001-09-19 20:52 ` Vojtech Pavlik
1 sibling, 1 reply; 44+ messages in thread
From: Arjan van de Ven @ 2001-09-19 19:21 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: Arjan van de Ven, linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 19:21 ` Arjan van de Ven
@ 2001-09-19 19:51 ` Dan Hollis
2001-09-19 19:59 ` Arjan van de Ven
` (2 more replies)
0 siblings, 3 replies; 44+ messages in thread
From: Dan Hollis @ 2001-09-19 19:51 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Petr Vandrovec, linux-kernel
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. [-]
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 19:51 ` Dan Hollis
@ 2001-09-19 19:59 ` Arjan van de Ven
2001-09-19 21:44 ` Eric W. Biederman
2001-09-21 17:22 ` bill davidsen
2 siblings, 0 replies; 44+ messages in thread
From: Arjan van de Ven @ 2001-09-19 19:59 UTC (permalink / raw)
To: Dan Hollis; +Cc: Arjan van de Ven, Petr Vandrovec, linux-kernel
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...
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 19:51 ` Dan Hollis
2001-09-19 19:59 ` Arjan van de Ven
@ 2001-09-19 21:44 ` Eric W. Biederman
2001-09-19 22:13 ` Dan Hollis
2001-09-21 17:22 ` bill davidsen
2 siblings, 1 reply; 44+ messages in thread
From: Eric W. Biederman @ 2001-09-19 21:44 UTC (permalink / raw)
To: Dan Hollis; +Cc: Arjan van de Ven, Petr Vandrovec, linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 21:44 ` Eric W. Biederman
@ 2001-09-19 22:13 ` Dan Hollis
2001-09-19 22:49 ` John Alvord
2001-09-19 22:55 ` Roberto Jung Drebes
0 siblings, 2 replies; 44+ messages in thread
From: Dan Hollis @ 2001-09-19 22:13 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Arjan van de Ven, Petr Vandrovec, linux-kernel
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. [-]
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 22:13 ` Dan Hollis
@ 2001-09-19 22:49 ` John Alvord
2001-09-19 23:14 ` Dan Hollis
2001-09-19 22:55 ` Roberto Jung Drebes
1 sibling, 1 reply; 44+ messages in thread
From: John Alvord @ 2001-09-19 22:49 UTC (permalink / raw)
To: Dan Hollis
Cc: Eric W. Biederman, Arjan van de Ven, Petr Vandrovec, linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 22:49 ` John Alvord
@ 2001-09-19 23:14 ` Dan Hollis
2001-09-19 23:32 ` Daniel T. Chen
0 siblings, 1 reply; 44+ messages in thread
From: Dan Hollis @ 2001-09-19 23:14 UTC (permalink / raw)
To: John Alvord
Cc: Eric W. Biederman, Arjan van de Ven, Petr Vandrovec, linux-kernel
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. [-]
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 23:14 ` Dan Hollis
@ 2001-09-19 23:32 ` Daniel T. Chen
0 siblings, 0 replies; 44+ messages in thread
From: Daniel T. Chen @ 2001-09-19 23:32 UTC (permalink / raw)
To: Dan Hollis; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 22:13 ` Dan Hollis
2001-09-19 22:49 ` John Alvord
@ 2001-09-19 22:55 ` Roberto Jung Drebes
1 sibling, 0 replies; 44+ messages in thread
From: Roberto Jung Drebes @ 2001-09-19 22:55 UTC (permalink / raw)
To: linux-kernel
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/
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 19:51 ` Dan Hollis
2001-09-19 19:59 ` Arjan van de Ven
2001-09-19 21:44 ` Eric W. Biederman
@ 2001-09-21 17:22 ` bill davidsen
2001-09-21 19:13 ` Dan Hollis
2 siblings, 1 reply; 44+ messages in thread
From: bill davidsen @ 2001-09-21 17:22 UTC (permalink / raw)
To: goemon; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-21 17:22 ` bill davidsen
@ 2001-09-21 19:13 ` Dan Hollis
0 siblings, 0 replies; 44+ messages in thread
From: Dan Hollis @ 2001-09-21 19:13 UTC (permalink / raw)
To: bill davidsen; +Cc: linux-kernel
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. [-]
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 21:15 Petr Vandrovec
2001-09-19 19:21 ` Arjan van de Ven
@ 2001-09-19 20:52 ` Vojtech Pavlik
1 sibling, 0 replies; 44+ messages in thread
From: Vojtech Pavlik @ 2001-09-19 20:52 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: Arjan van de Ven, linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 13:47 Re[2]: " Thomas Langås
@ 2001-09-19 14:31 Liakakis Kostas
2001-09-19 14:43 ` Stefan Smietanowski
0 siblings, 1 reply; 44+ messages in thread
From: Liakakis Kostas @ 2001-09-19 14:31 UTC (permalink / raw)
To: linux-kernel
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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 14:31 Re[2]: " Liakakis Kostas
@ 2001-09-19 14:43 ` Stefan Smietanowski
0 siblings, 0 replies; 44+ messages in thread
From: Stefan Smietanowski @ 2001-09-19 14:43 UTC (permalink / raw)
To: Liakakis Kostas; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.
@ 2001-09-19 13:47 Thomas Langås
2001-09-19 14:55 ` Jan Niehusmann
0 siblings, 1 reply; 44+ messages in thread
From: Thomas Langås @ 2001-09-19 13:47 UTC (permalink / raw)
To: Liakakis Kostas; +Cc: VDA, linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 14:31 Re[2]: " Liakakis Kostas
@ 2001-09-19 14:55 ` Jan Niehusmann
2001-09-19 16:00 ` Linus Torvalds
0 siblings, 1 reply; 44+ messages in thread
From: Jan Niehusmann @ 2001-09-19 14:55 UTC (permalink / raw)
To: Liakakis Kostas; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 14:55 ` Jan Niehusmann
@ 2001-09-19 16:00 ` Linus Torvalds
2001-09-19 17:15 ` safemode
` (2 more replies)
0 siblings, 3 replies; 44+ messages in thread
From: Linus Torvalds @ 2001-09-19 16:00 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 16:00 ` Linus Torvalds
@ 2001-09-19 17:15 ` safemode
2001-09-19 18:22 ` Stefan Smietanowski
2001-09-19 18:43 ` Re[2]: " Dan Hollis
2001-09-20 0:19 ` Re[2]: " Nicholas Knight
2 siblings, 1 reply; 44+ messages in thread
From: safemode @ 2001-09-19 17:15 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel
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/
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 17:15 ` safemode
@ 2001-09-19 18:22 ` Stefan Smietanowski
0 siblings, 0 replies; 44+ messages in thread
From: Stefan Smietanowski @ 2001-09-19 18:22 UTC (permalink / raw)
To: safemode; +Cc: Linus Torvalds, linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 16:00 ` Linus Torvalds
2001-09-19 17:15 ` safemode
@ 2001-09-19 18:43 ` Dan Hollis
2001-09-19 18:55 ` Arjan van de Ven
` (2 more replies)
2001-09-20 0:19 ` Re[2]: " Nicholas Knight
2 siblings, 3 replies; 44+ messages in thread
From: Dan Hollis @ 2001-09-19 18:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
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. [-]
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 18:43 ` Re[2]: " Dan Hollis
@ 2001-09-19 18:55 ` Arjan van de Ven
2001-09-19 19:00 ` Roberto Jung Drebes
` (3 more replies)
2001-09-19 20:36 ` Simen Thoresen
2001-09-20 9:03 ` VDA
2 siblings, 4 replies; 44+ messages in thread
From: Arjan van de Ven @ 2001-09-19 18:55 UTC (permalink / raw)
To: Dan Hollis; +Cc: linux-kernel
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
.....
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 18:55 ` Arjan van de Ven
@ 2001-09-19 19:00 ` Roberto Jung Drebes
2001-09-19 19:17 ` Arjan van de Ven
2001-09-19 20:16 ` Dan Hollis
2001-09-19 19:50 ` Ignacio Vazquez-Abrams
` (2 subsequent siblings)
3 siblings, 2 replies; 44+ messages in thread
From: Roberto Jung Drebes @ 2001-09-19 19:00 UTC (permalink / raw)
To: linux-kernel
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/
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 19:00 ` Roberto Jung Drebes
@ 2001-09-19 19:17 ` Arjan van de Ven
2001-09-19 20:16 ` Dan Hollis
1 sibling, 0 replies; 44+ messages in thread
From: Arjan van de Ven @ 2001-09-19 19:17 UTC (permalink / raw)
To: Roberto Jung Drebes; +Cc: linux-kernel
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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 19:00 ` Roberto Jung Drebes
2001-09-19 19:17 ` Arjan van de Ven
@ 2001-09-19 20:16 ` Dan Hollis
1 sibling, 0 replies; 44+ messages in thread
From: Dan Hollis @ 2001-09-19 20:16 UTC (permalink / raw)
To: Roberto Jung Drebes; +Cc: linux-kernel
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. [-]
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 18:55 ` Arjan van de Ven
2001-09-19 19:00 ` Roberto Jung Drebes
@ 2001-09-19 19:50 ` Ignacio Vazquez-Abrams
2001-09-19 20:01 ` Ignacio Vazquez-Abrams
2001-09-19 20:36 ` Vojtech Pavlik
2001-09-19 23:23 ` Luigi Genoni
3 siblings, 1 reply; 44+ messages in thread
From: Ignacio Vazquez-Abrams @ 2001-09-19 19:50 UTC (permalink / raw)
To: linux-kernel
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>
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 19:50 ` Ignacio Vazquez-Abrams
@ 2001-09-19 20:01 ` Ignacio Vazquez-Abrams
2001-09-19 20:40 ` Ignacio Vazquez-Abrams
0 siblings, 1 reply; 44+ messages in thread
From: Ignacio Vazquez-Abrams @ 2001-09-19 20:01 UTC (permalink / raw)
To: linux-kernel
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>
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 20:01 ` Ignacio Vazquez-Abrams
@ 2001-09-19 20:40 ` Ignacio Vazquez-Abrams
2001-09-19 21:43 ` safemode
0 siblings, 1 reply; 44+ messages in thread
From: Ignacio Vazquez-Abrams @ 2001-09-19 20:40 UTC (permalink / raw)
To: linux-kernel
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>
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 20:40 ` Ignacio Vazquez-Abrams
@ 2001-09-19 21:43 ` safemode
2001-09-19 22:22 ` Brad Pepers
0 siblings, 1 reply; 44+ messages in thread
From: safemode @ 2001-09-19 21:43 UTC (permalink / raw)
To: Ignacio Vazquez-Abrams, linux-kernel
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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 21:43 ` safemode
@ 2001-09-19 22:22 ` Brad Pepers
2001-09-19 22:28 ` Erno Kuusela
0 siblings, 1 reply; 44+ messages in thread
From: Brad Pepers @ 2001-09-19 22:22 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 22:22 ` Brad Pepers
@ 2001-09-19 22:28 ` Erno Kuusela
0 siblings, 0 replies; 44+ messages in thread
From: Erno Kuusela @ 2001-09-19 22:28 UTC (permalink / raw)
To: Brad Pepers; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 18:55 ` Arjan van de Ven
2001-09-19 19:00 ` Roberto Jung Drebes
2001-09-19 19:50 ` Ignacio Vazquez-Abrams
@ 2001-09-19 20:36 ` Vojtech Pavlik
2001-09-19 20:57 ` Dan Hollis
2001-09-19 23:23 ` Luigi Genoni
3 siblings, 1 reply; 44+ messages in thread
From: Vojtech Pavlik @ 2001-09-19 20:36 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Dan Hollis, linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 20:36 ` Vojtech Pavlik
@ 2001-09-19 20:57 ` Dan Hollis
2001-09-19 21:29 ` Vojtech Pavlik
0 siblings, 1 reply; 44+ messages in thread
From: Dan Hollis @ 2001-09-19 20:57 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Arjan van de Ven, linux-kernel
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. [-]
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 20:57 ` Dan Hollis
@ 2001-09-19 21:29 ` Vojtech Pavlik
0 siblings, 0 replies; 44+ messages in thread
From: Vojtech Pavlik @ 2001-09-19 21:29 UTC (permalink / raw)
To: Dan Hollis; +Cc: Arjan van de Ven, linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 18:55 ` Arjan van de Ven
` (2 preceding siblings ...)
2001-09-19 20:36 ` Vojtech Pavlik
@ 2001-09-19 23:23 ` Luigi Genoni
3 siblings, 0 replies; 44+ messages in thread
From: Luigi Genoni @ 2001-09-19 23:23 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Dan Hollis, linux-kernel
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/
>
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 18:43 ` Re[2]: " Dan Hollis
2001-09-19 18:55 ` Arjan van de Ven
@ 2001-09-19 20:36 ` Simen Thoresen
2001-09-19 20:37 ` Dan Hollis
2001-09-20 9:03 ` VDA
2 siblings, 1 reply; 44+ messages in thread
From: Simen Thoresen @ 2001-09-19 20:36 UTC (permalink / raw)
To: arjanv; +Cc: linux-kernel
>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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 20:36 ` Simen Thoresen
@ 2001-09-19 20:37 ` Dan Hollis
2001-09-19 20:51 ` Simen Thoresen
0 siblings, 1 reply; 44+ messages in thread
From: Dan Hollis @ 2001-09-19 20:37 UTC (permalink / raw)
To: Simen Thoresen; +Cc: arjanv, linux-kernel
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. [-]
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 20:37 ` Dan Hollis
@ 2001-09-19 20:51 ` Simen Thoresen
2001-09-19 23:00 ` Roberto Jung Drebes
0 siblings, 1 reply; 44+ messages in thread
From: Simen Thoresen @ 2001-09-19 20:51 UTC (permalink / raw)
To: goemon; +Cc: linux-kernel
>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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 20:51 ` Simen Thoresen
@ 2001-09-19 23:00 ` Roberto Jung Drebes
0 siblings, 0 replies; 44+ messages in thread
From: Roberto Jung Drebes @ 2001-09-19 23:00 UTC (permalink / raw)
To: Simen Thoresen; +Cc: goemon, linux-kernel
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/
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 18:43 ` Re[2]: " Dan Hollis
2001-09-19 18:55 ` Arjan van de Ven
2001-09-19 20:36 ` Simen Thoresen
@ 2001-09-20 9:03 ` VDA
2 siblings, 0 replies; 44+ messages in thread
From: VDA @ 2001-09-20 9:03 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel
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/
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.
2001-09-19 16:00 ` Linus Torvalds
2001-09-19 17:15 ` safemode
2001-09-19 18:43 ` Re[2]: " Dan Hollis
@ 2001-09-20 0:19 ` Nicholas Knight
2001-09-20 1:27 ` Stefan Smietanowski
2 siblings, 1 reply; 44+ messages in thread
From: Nicholas Knight @ 2001-09-20 0:19 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel
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?
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-20 0:19 ` Re[2]: " Nicholas Knight
@ 2001-09-20 1:27 ` Stefan Smietanowski
0 siblings, 0 replies; 44+ messages in thread
From: Stefan Smietanowski @ 2001-09-20 1:27 UTC (permalink / raw)
To: tegeran; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] Athlon bug stomper. Pls apply.
@ 2001-09-18 14:51 VDA
2001-09-18 15:43 ` Alan Cox
` (3 more replies)
0 siblings, 4 replies; 44+ messages in thread
From: VDA @ 2001-09-18 14:51 UTC (permalink / raw)
To: linux-kernel
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 },
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-18 14:51 VDA
@ 2001-09-18 15:43 ` Alan Cox
2001-09-20 4:56 ` Albert D. Cahalan
2001-09-18 17:45 ` Jeff Garzik
` (2 subsequent siblings)
3 siblings, 1 reply; 44+ messages in thread
From: Alan Cox @ 2001-09-18 15:43 UTC (permalink / raw)
To: VDA; +Cc: linux-kernel
> 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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-18 15:43 ` Alan Cox
@ 2001-09-20 4:56 ` Albert D. Cahalan
0 siblings, 0 replies; 44+ messages in thread
From: Albert D. Cahalan @ 2001-09-20 4:56 UTC (permalink / raw)
To: Alan Cox; +Cc: VDA, linux-kernel
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?
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-18 14:51 VDA
2001-09-18 15:43 ` Alan Cox
@ 2001-09-18 17:45 ` Jeff Garzik
2001-09-18 21:39 ` Liakakis Kostas
2001-09-23 23:33 ` Jan Niehusmann
3 siblings, 0 replies; 44+ messages in thread
From: Jeff Garzik @ 2001-09-18 17:45 UTC (permalink / raw)
To: VDA; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-18 14:51 VDA
2001-09-18 15:43 ` Alan Cox
2001-09-18 17:45 ` Jeff Garzik
@ 2001-09-18 21:39 ` Liakakis Kostas
2001-09-23 23:33 ` Jan Niehusmann
3 siblings, 0 replies; 44+ messages in thread
From: Liakakis Kostas @ 2001-09-18 21:39 UTC (permalink / raw)
To: VDA; +Cc: linux-kernel
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]
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-18 14:51 VDA
` (2 preceding siblings ...)
2001-09-18 21:39 ` Liakakis Kostas
@ 2001-09-23 23:33 ` Jan Niehusmann
2001-09-24 15:44 ` bill davidsen
3 siblings, 1 reply; 44+ messages in thread
From: Jan Niehusmann @ 2001-09-23 23:33 UTC (permalink / raw)
To: VDA; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] Athlon bug stomper. Pls apply.
2001-09-23 23:33 ` Jan Niehusmann
@ 2001-09-24 15:44 ` bill davidsen
0 siblings, 0 replies; 44+ messages in thread
From: bill davidsen @ 2001-09-24 15:44 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2001-09-24 15:44 UTC | newest]
Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-09-19 23:33 [PATCH] Athlon bug stomper. Pls apply Leif Sawyer
-- strict thread matches above, loose matches on Subject: below --
2001-09-20 13:08 Petr Vandrovec
2001-09-19 21:15 Petr Vandrovec
2001-09-19 19:21 ` Arjan van de Ven
2001-09-19 19:51 ` Dan Hollis
2001-09-19 19:59 ` Arjan van de Ven
2001-09-19 21:44 ` Eric W. Biederman
2001-09-19 22:13 ` Dan Hollis
2001-09-19 22:49 ` John Alvord
2001-09-19 23:14 ` Dan Hollis
2001-09-19 23:32 ` Daniel T. Chen
2001-09-19 22:55 ` Roberto Jung Drebes
2001-09-21 17:22 ` bill davidsen
2001-09-21 19:13 ` Dan Hollis
2001-09-19 20:52 ` Vojtech Pavlik
2001-09-19 14:31 Re[2]: " Liakakis Kostas
2001-09-19 14:43 ` Stefan Smietanowski
2001-09-19 13:47 Re[2]: " Thomas Langås
2001-09-19 14:55 ` Jan Niehusmann
2001-09-19 16:00 ` Linus Torvalds
2001-09-19 17:15 ` safemode
2001-09-19 18:22 ` Stefan Smietanowski
2001-09-19 18:43 ` Re[2]: " Dan Hollis
2001-09-19 18:55 ` Arjan van de Ven
2001-09-19 19:00 ` Roberto Jung Drebes
2001-09-19 19:17 ` Arjan van de Ven
2001-09-19 20:16 ` Dan Hollis
2001-09-19 19:50 ` Ignacio Vazquez-Abrams
2001-09-19 20:01 ` Ignacio Vazquez-Abrams
2001-09-19 20:40 ` Ignacio Vazquez-Abrams
2001-09-19 21:43 ` safemode
2001-09-19 22:22 ` Brad Pepers
2001-09-19 22:28 ` Erno Kuusela
2001-09-19 20:36 ` Vojtech Pavlik
2001-09-19 20:57 ` Dan Hollis
2001-09-19 21:29 ` Vojtech Pavlik
2001-09-19 23:23 ` Luigi Genoni
2001-09-19 20:36 ` Simen Thoresen
2001-09-19 20:37 ` Dan Hollis
2001-09-19 20:51 ` Simen Thoresen
2001-09-19 23:00 ` Roberto Jung Drebes
2001-09-20 9:03 ` VDA
2001-09-20 0:19 ` Re[2]: " Nicholas Knight
2001-09-20 1:27 ` Stefan Smietanowski
2001-09-18 14:51 VDA
2001-09-18 15:43 ` Alan Cox
2001-09-20 4:56 ` Albert D. Cahalan
2001-09-18 17:45 ` Jeff Garzik
2001-09-18 21:39 ` Liakakis Kostas
2001-09-23 23:33 ` Jan Niehusmann
2001-09-24 15:44 ` bill davidsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).