Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Seth Goldberg]

Hi :)

  And that's exactly what I did :)...  I found that ONLY the combination
of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in
mmx.c)
results in this wackiness.  I should alos repeat that I *DO* see that
wierdness you described with 3DNOW (in my case, it was that kde locks
up when i try to do something).

 This is damn weird... Who thought channging motherboards would result
in this?

  The other thing i was gunna try is to dump my chipset registers using 
WPCREDIT and WPCRSET and compare them with other people on this list
who have been having the problem.  Maybe our BIOS'es are not
initting/are initting something they should/should not be :).  It this
point, I haven't ruled anything out...

 --Seth


Lawrence Gold wrote:
> 
> Hi, Seth,
> 
> Just wanted to let you know that I got similar results to yours with my
> Epox 8KTA3 motherboard + Thunderbird.  (If you've already seen the thread
> on the kernel mailing list, then please ignore this. ;)
> 
> If I leave the 3DNOW stuff enabled in arch/i386/config.in, but disable the
> K7-specific MMX optimizations, then the system doesn't panic on startup or
> oops continually, but I do get odd behavior, such as awk breaking.
> 
> If I disable just the 3DNOW stuff, then everything works really smoothly.
> I was planning on disabling one-by-one the parts of the code which use
> 3DNOW optimizations to see if there's a particular one that brings about
> instability.
> 
> I'll be sure to cc you on anything I find...

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Mark Hahn]

>   And that's exactly what I did :)...  I found that ONLY the combination
> of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in
> results in this wackiness.  I should alos repeat that I *DO* see that

I doubt that USE_3DNOW is causing the problem, but rather when you
USE_3DNOW, the kernel streams through your northbridge at roughly
twice the bandwidth.  if your dram settings are flakey, this could
eaily trigger a problem.  

this has nothing to do with the very specific disk corruption
being discussed (which has to do with the ide controller, according
to the most recent rumors.).

>   The other thing i was gunna try is to dump my chipset registers using 
> WPCREDIT and WPCRSET and compare them with other people on this list

why resort to silly windows tools, when lspci under Linux does it for you?

regards, mark hahn.

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Seth Goldberg]

Mark Hahn wrote:
> 
> >   And that's exactly what I did :)...  I found that ONLY the combination
> > of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in
> > results in this wackiness.  I should alos repeat that I *DO* see that
> 
> I doubt that USE_3DNOW is causing the problem, but rather when you
> USE_3DNOW, the kernel streams through your northbridge at roughly
> twice the bandwidth.  if your dram settings are flakey, this could
> eaily trigger a problem.
> 
> this has nothing to do with the very specific disk corruption
> being discussed (which has to do with the ide controller, according
> to the most recent rumors.).

  Actually, I think there are 2 problems that have been discussed -- the
disk corruption and a general instability resulting in oops'es at
various points shortly after boot up.

  My memory system jas been set up very conservitavely and has been
rock solid in my other board (ka7), so I doubt it's that, but I
sure am happy to try a few more cominations of bios settings.  Anything
I should look for in particular?

  Thanks,
   Seth

> 
> >   The other thing i was gunna try is to dump my chipset registers using
> > WPCREDIT and WPCRSET and compare them with other people on this list
> 
> why resort to silly windows tools, when lspci under Linux does it for you?
> 
> regards, mark hahn.
> 

  Because lspci does not display all 256 bytes of pci configuration
information.


  --S

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Wayne Whitney]

In mailing-lists.linux-kernel, Seth wrote:

>  Because lspci does not display all 256 bytes of pci configuration
>information.

Umm, "lspci -xxx"?  At least, on lspci version 2.1.8 from RedHat 7.1.

Wayne

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Mark Hahn]

> > this has nothing to do with the very specific disk corruption
> > being discussed (which has to do with the ide controller, according
> > to the most recent rumors.).
> 
>   Actually, I think there are 2 problems that have been discussed -- the
> disk corruption and a general instability resulting in oops'es at
> various points shortly after boot up.

I don't see this.  specifically, there were scattered reports
of a via-ide problem a few months ago; this is the issue that's 
gotten some press, and for which Alan has a fix.  and there are reports 
of via-smp problems at boot (which go away with noapic).  I see no reports 
of the kind of general instability you're talking about.  and all the 
via-users I've heard of have no such stability problems - 
me included (kt133/duron).

the only general issue is that kx133 systems seem to be difficult
to configure for stability.  ugly things like tweaking Vio.
there's no implication that has anything to do with Linux, though.
> 
>   My memory system jas been set up very conservitavely and has been
> rock solid in my other board (ka7), so I doubt it's that, but I
> sure am happy to try a few more cominations of bios settings.  Anything
> I should look for in particular?

how many dimms do you have?  interleave settings?  Vio jumper?
already checked on cooling issues?  and that you're not overclocking...

> > why resort to silly windows tools, when lspci under Linux does it for you?
> 
>   Because lspci does not display all 256 bytes of pci configuration
> information.

sure it does: (from my kt133 hostbridge)

[root@crema /root]# lspci -s 00:00.0 -xxx
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
00: 06 11 05 03 06 00 10 22 02 00 00 06 00 00 00 00
10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 27 a4 0b b4 46 02 08 08 08 00 00 00 04 08 08 08
60: 0c 00 00 00 d5 d6 d5 00 50 5d 86 0d 08 01 00 00
70: c9 88 cc 0c 0e a0 d2 00 01 b4 01 02 00 00 00 00
80: 0f 40 00 00 f0 00 00 00 02 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2b 02 04 00
b0: 7f 63 2a 65 31 33 c0 0c 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 0e 22 00 00 00 00 00 00 00

[root@crema /root]# od -Ax -txC /proc/bus/pci/00/00.0 
000000 06 11 05 03 06 00 10 22 02 00 00 06 00 00 00 00
000010 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00
000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000030 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000050 27 a4 0b b4 46 02 08 08 08 00 00 00 04 08 08 08
000060 0c 00 00 00 d5 d6 d5 00 50 5d 86 0d 08 01 00 00
000070 c9 88 cc 0c 0e a0 d2 00 01 b4 01 02 00 00 00 00
000080 0f 40 00 00 f0 00 00 00 02 00 00 00 00 00 00 00
000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000a0 02 c0 20 00 07 02 00 1f 00 00 00 00 2b 02 04 00
0000b0 7f 63 2a 65 31 33 c0 0c 00 00 00 00 00 00 00 00
0000c0 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
0000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000f0 00 00 00 00 00 00 00 0e 22 00 00 00 00 00 00 00
000100

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Moses McKnight]

Mark Hahn wrote:

>>  Actually, I think there are 2 problems that have been discussed -- the
>>disk corruption and a general instability resulting in oops'es at
>>various points shortly after boot up.
>>
> 
> I don't see this.  specifically, there were scattered reports
> of a via-ide problem a few months ago; this is the issue that's 
> gotten some press, and for which Alan has a fix.  and there are reports 
> of via-smp problems at boot (which go away with noapic).  I see no reports 
> of the kind of general instability you're talking about.  and all the 
> via-users I've heard of have no such stability problems - 
> me included (kt133/duron).
> 
> the only general issue is that kx133 systems seem to be difficult
> to configure for stability.  ugly things like tweaking Vio.
> there's no implication that has anything to do with Linux, though.


When I reported my problem a couple weeks back another fellow
said he and several others on the list had the same problem,
and as far as I can tell it is *only* with the IWILL boards.
When I compiled with k7 optimizations I'd get all kinds of oopses
and panics and never fully boot.  They were different every time.
When any of the lesser optimizations are used I have no problems.
My memory is one 256MB Corsair PC150 dimm, CPU is a Thunderbird 850,
and mobo is an IWILL KK266 (KT133A).  The CPU runs between 35°C
and 40°C.


>>  My memory system jas been set up very conservitavely and has been
>>rock solid in my other board (ka7), so I doubt it's that, but I
>>sure am happy to try a few more cominations of bios settings.  Anything
>>I should look for in particular?
>>
> 
> how many dimms do you have?  interleave settings?  Vio jumper?
> already checked on cooling issues?  and that you're not overclocking...

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Alan Cox]

> > why resort to silly windows tools, when lspci under Linux does it for you?
> 
>   Because lspci does not display all 256 bytes of pci configuration
> information.

RTFM ;)

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Jonathan Morton]

>> the only general issue is that kx133 systems seem to be difficult
>> to configure for stability.  ugly things like tweaking Vio.
>> there's no implication that has anything to do with Linux, though.
>
>
>When I reported my problem a couple weeks back another fellow
>said he and several others on the list had the same problem,
>and as far as I can tell it is *only* with the IWILL boards.
>When I compiled with k7 optimizations I'd get all kinds of oopses
>and panics and never fully boot.  They were different every time.
>When any of the lesser optimizations are used I have no problems.
>My memory is one 256MB Corsair PC150 dimm, CPU is a Thunderbird 850,
>and mobo is an IWILL KK266 (KT133A).  The CPU runs between 35°C
>and 40°C.

I'm using an Abit KT7 board (KT133) and my new 1GHz T'bird (running 50-60°C
in a warm room) is giving me no trouble.  This is with the board and RAM
pushed as fast as it will go without actually overclocking anything...  and
yes, I do have Athlon/K7 optimisations turned on in my kernel (2.4.3).

Out of interest, what FSB are you using for your machine?  I understand the
difference between the KT133 and the KT133A is that the latter supports a
266MHz FSB for the Athlon rather than 200MHz.  Since your CPU is running
cool, I doubt you've managed to accidentally o/c it, but nevertheless this
is a possibility...

The 266MHz FSB does require considerably higher standards in board
construction though, so it could be that IWILL have managed to do a shoddy
job on that end.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Dan Hollis]

On Tue, 1 May 2001, Seth Goldberg wrote:
> > >   The other thing i was gunna try is to dump my chipset registers using
> > > WPCREDIT and WPCRSET and compare them with other people on this list
> > why resort to silly windows tools, when lspci under Linux does it for you?
>   Because lspci does not display all 256 bytes of pci configuration
> information.

Say what?

Try lspci -vvxxx

-Dan

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Seth Goldberg]

  Thanks moses -- this is the instability that I have as well.
I tried compiling on 1/2 of the k7 optimized mmx routines.
So far, running with JUST the fast_clear_page using k7 streaming (and
not
fast_copy_page), the system is still stable.  I'll try adding fast_copy
_page, but I think that's where our problems lie (of course I could be
full of crap,  too).

 --S

Moses McKnight wrote:
> 
> Mark Hahn wrote:
> 
> >>  Actually, I think there are 2 problems that have been discussed -- the
> >>disk corruption and a general instability resulting in oops'es at
> >>various points shortly after boot up.
> >>
> >
> > I don't see this.  specifically, there were scattered reports
> > of a via-ide problem a few months ago; this is the issue that's
> > gotten some press, and for which Alan has a fix.  and there are reports
> > of via-smp problems at boot (which go away with noapic).  I see no reports
> > of the kind of general instability you're talking about.  and all the
> > via-users I've heard of have no such stability problems -
> > me included (kt133/duron).
> >
> > the only general issue is that kx133 systems seem to be difficult
> > to configure for stability.  ugly things like tweaking Vio.
> > there's no implication that has anything to do with Linux, though.
> 
> When I reported my problem a couple weeks back another fellow
> said he and several others on the list had the same problem,
> and as far as I can tell it is *only* with the IWILL boards.
> When I compiled with k7 optimizations I'd get all kinds of oopses
> and panics and never fully boot.  They were different every time.
> When any of the lesser optimizations are used I have no problems.
> My memory is one 256MB Corsair PC150 dimm, CPU is a Thunderbird 850,
> and mobo is an IWILL KK266 (KT133A).  The CPU runs between 35°C
> and 40°C.
> 
> >>  My memory system jas been set up very conservitavely and has been
> >>rock solid in my other board (ka7), so I doubt it's that, but I
> >>sure am happy to try a few more cominations of bios settings.  Anything
> >>I should look for in particular?
> >>
> >
> > how many dimms do you have?  interleave settings?  Vio jumper?
> > already checked on cooling issues?  and that you're not overclocking...
> 
> -
> 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Seth Goldberg]

Jonathan Morton wrote:

> 
> I'm using an Abit KT7 board (KT133) and my new 1GHz T'bird (running 50-60°C
> in a warm room) is giving me no trouble.  This is with the board and RAM
> pushed as fast as it will go without actually overclocking anything...  and
> yes, I do have Athlon/K7 optimisations turned on in my kernel (2.4.3).
> 

  I wonder if the KT133A (which is what the IWILL KK266 is based on)
differences
a could be a source of the problem.  My FSB is at plain old 100 MHz
since I
have regular PC100 SDRAM.  Overclocked, or not, I get the same results. 
I,
too, had an ABIT KA7[-RAID] and it was rock solid.  So much for "if it's
not broke, don't fix it" -- I should have listened to my gf, but that's
the life of an upgrader ;)...  In general the IWILL got great reviews at
a
number of reliable hardware review sites, and hey, it doesn't lock up in
windows ;) (ok don't flame me for that ;)).

 --Seth

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Jonathan Morton]

>> I'm using an Abit KT7 board (KT133) and my new 1GHz T'bird (running 50-60°C
>> in a warm room) is giving me no trouble.  This is with the board and RAM
>> pushed as fast as it will go without actually overclocking anything...  and
>> yes, I do have Athlon/K7 optimisations turned on in my kernel (2.4.3).
>>
>
>  I wonder if the KT133A (which is what the IWILL KK266 is based on)
>differences
>a could be a source of the problem.  My FSB is at plain old 100 MHz
>since I
>have regular PC100 SDRAM.  Overclocked, or not, I get the same results.
>I,
>too, had an ABIT KA7[-RAID] and it was rock solid.  So much for "if it's
>not broke, don't fix it" -- I should have listened to my gf, but that's
>the life of an upgrader ;)...  In general the IWILL got great reviews at
>a
>number of reliable hardware review sites, and hey, it doesn't lock up in
>windows ;) (ok don't flame me for that ;)).

Maybe, but the IWILL board is the only one we've heard about problems with.
The Abit KT7A (which also has the KT133A chipset and is otherwise identical
to the KT7) would appear to run smoothly, although I don't actually *have*
one of those.  Probably the Windows drivers turn off some feature of the
IWILL board which is known to be flaky.

I suggest setting *everything* in the BIOS to the "most conservative"
settings and seeing if the problem persists.  If so, then it can't be a
hardware-speed-limitation problem, and there's clearly something we have to
turn off "manually".  Also, try running memtest86 and see if that is
capable of triggering the problem.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Ray Shaw]

I don't know if it's the motherboard, but I've got a KT7A-RAID, and I
haven't been able to run any 2.4.x that I've tried.  I was worried,
because this board also has new RAM, but 2.2.x doesn't have any
problems at all.

I've tried:

2.4.2
2.4.3
2.4.3-ac9
2.4.3-ac11

Someone else mentioned stability problems with nVida and AGP, which
I'm also using.  It's true that I've only experienced lockups under X.

Things I haven't tried, but should (and will, once finals are over):

2.4.x, unoptimised
2.4.x, optimised, disable AGP

I'm running Debian unstable (but it's not unstable with 2.2.x :)


-- 
--Ray

-----------------------------
Sotto la panca la capra crepa
sopra la panca la capra campa

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Christian Bornträger]

> Mandrake 8's kernel comes with i586 CPU support, it is alredy known it
> works. Remember that the instability occurs only when Athlon optimizations
> are used.

You are right.
But I like to point out that on my Athlon kernel 2.4.3 is working fine.
The first kernel  I face problems is 2.4.3-ac7.  I also know that the
problem occurs of kernel 2.4.4.
That might help to find the problem.

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Dan Podeanu]

> No matter if I use the mandrake 8 gcc 2.96 or a self compiled gcc 2.95.3.

Mandrake 8's kernel comes with i586 CPU support, it is alredy known it
works. Remember that the instability occurs only when Athlon optimizations
are used.

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Christian Bornträger]

>Maybe, but the IWILL board is the only one we've heard about problems with.

I have also stability problems with an ASUS A7V133. I already have the
1004-d2 bios which should fix the VIA IDE problems. But my hard drives are
connected to the promise controller of the board. Only 2 CD-drives are on
teh VIA-Chip.

I am quite sure that my problem was introduced with 2.4.3-ac7, because, the
board is rock solid up to kernel 2.4.3-ac6 or with the Madrake 8 kernel.
But If I try to put some load on 2.4.3-ac7 or above I get lock ups. Even the
magic sysrq does not work. No matter if compiled for athlon Pentium II or
586.
No matter if I use the mandrake 8 gcc 2.96 or a self compiled gcc 2.95.3.
The problem also occurs on kernel 2.4.4.


Bytheway there is a thread called "ABit KT7A-RAIN random lock ups "
It might be related to one of the Athlon/VIA problems.



greetings
Christian

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Seth Goldberg]

Dan Hollis wrote:
> 
> On Tue, 1 May 2001, Seth Goldberg wrote:
> >   I Should clarify that this is the KX133A chipset.
> 
> No such thing. Surely you mean KT133A. No X.
> 

   Surely :)... That's what sleep deprivation does to you ;).

 --S

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Dan Hollis]

On Tue, 1 May 2001, Seth Goldberg wrote:
>   I Should clarify that this is the KX133A chipset.

No such thing. Surely you mean KT133A. No X.

-Dan

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Seth Goldberg]

Will Newton wrote:

  I Should clarify that this is the KX133A chipset.  In any event,
there are a bunch of people having this problem (check out the list
archives).  I just upgraded to this IWILL board from an Abit KA7-RAID
(which worked with no problem), so I'm just trying tofgure it out :)

 -Seth

> 
> > is exhibiting weird behavior under K7 optimizations. The jist of my
> > research is that compiling a kernel for ANY CPU with the Athlon MMX
> > optimization
> > *AND* 3DNOW results in massive amounts of oops'es and total system
> > instability. The following is what I've tried:
> 
> With:
> 
> Athlon 700
> Asus K7V (KX133 based)
> 
> I have been running Athlon based kernels for months, no problems (well,
> none like you mention).
> 
> gcc 2.96-81 BTW
> 
> -
> 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: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Will Newton]

> is exhibiting weird behavior under K7 optimizations. The jist of my
> research is that compiling a kernel for ANY CPU with the Athlon MMX
> optimization
> *AND* 3DNOW results in massive amounts of oops'es and total system
> instability. The following is what I've tried:

With:

Athlon 700
Asus K7V (KX133 based)

I have been running Athlon based kernels for months, no problems (well,
none like you mention).

gcc 2.96-81 BTW

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Alan Cox]

>       when I add USE_3DNOW to the K6 section and reboot, KDE hangs when
>       I click on any button in my launch bar (vanilla KDE 2.0).  It
>       does NOT hang the system, though.  Restarting Xwindows does not
> help,

The K6 USE_3DNOW has two problems

1.	It doesnt work on a CPU with fxsave (my bug and its fixed in -ac)
2.	Its not a performance win. 

#2 doesn't matter for testing

>   [3] When I add 3DNOW to any option in [2] w/ the Athlon MMX opt,
>       the instability is evident after root is mounted and startup
>       scripts begin executing.  Sometimes the system can make it through
>       other times it cannot.

And I still have no problem reporters with non VIA chipsets....

Alan

DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Seth Goldberg]

Ok, so the subject is an attention-getter :).

Peep this, homies:

Hi,

  I've been doing some research, trying to figure out why the VIA/Athlon
is exhibiting weird behavior under K7 optimizations.  The jist of my 
research is that compiling a kernel for ANY CPU with the Athlon MMX
optimization
*AND* 3DNOW results in massive amounts of oops'es and total system
instability.  The following is what I've tried:

  [1] Selected Athlon as CPU in .config, then commenting out (#if 0) 
      the mmx code optimized for the athlon (as was stated is the only
      main k7 opt).  The resulting kernel is stable.  enabling/disabling
      other options have no effect on stability.

  [2] Experimented with choosing K6-(III) optimized kernel, but
modifying
      the arch/i386/config.in to sequentially add to the K6 section all
the
      options in the K7 section (i.e. GOOD_APIC, USE_3DNOW,
L1_CACHE_SHIFT
      difference, and PGE).  So far, the only anomolay I've found is
that
      when I add USE_3DNOW to the K6 section and reboot, KDE hangs when
      I click on any button in my launch bar (vanilla KDE 2.0).  It
      does NOT hang the system, though.  Restarting Xwindows does not
help,
      but changing the WM to TWM allows me to run netscape (which was
one
      of the buttons that hund X in KDE in the launch bar). Weird,
right?
      Enabling paging extensions (CONFIG_X86_PGE) appears to have
      no effect on stability.

  [3] When I add 3DNOW to any option in [2] w/ the Athlon MMX opt,
      the instability is evident after root is mounted and startup
      scripts begin executing.  Sometimes the system can make it through
      other times it cannot.

Athlon 900 (990) Thunderbird
IWILL KK-266 M/B
256MB PC100 RAM
Promise Ultra66 IDE
SB Live
GeForce 256 (AGP)

My info (dmesg):
================
Linux version 2.4.4 (root@c1162825-a) (gcc version 2.95.3 20010315
(release)) #6 SMP Sun Apr 29 04:31:06 PDT 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
 BIOS-e820: 000000000fff0000 - 000000000fff3000 (ACPI NVS)
 BIOS-e820: 000000000fff3000 - 0000000010000000 (ACPI data)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
Scan SMP from c0000000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f0000 for 65536 bytes.
Scan SMP from c009fc00 for 4096 bytes.
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
mapped APIC to ffffe000 (01444000)
Kernel command line: BOOT_IMAGE=LInux ro root=302
Initializing CPU#0
Detected 993.350 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1979.18 BogoMIPS
Memory: 255644k/262080k available (846k kernel code, 6048k reserved,
334k data, 188k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU0: AMD Athlon(tm) Processor stepping 02
per-CPU timeslice cutoff: 731.63 usecs.
SMP motherboard not detected. Using dummy APIC emulation.
Setting commenced=1, go go go
PCI: PCI BIOS revision 2.10 entry at 0xfb240, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
Applying VIA PCI latency patch.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 169848kB/56616kB, 512 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
    ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:DMA, hdd:DMA
PDC20262: IDE controller on PCI bus 00 dev 68
PCI: Found IRQ 10 for device 00:0d.0
PDC20262: chipset revision 1
PDC20262: not 100% native mode: will probe irqs later
PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
    ide2: BM-DMA at 0xe400-0xe407, BIOS settings: hde:DMA, hdf:pio
    ide3: BM-DMA at 0xe408-0xe40f, BIOS settings: hdg:DMA, hdh:DMA
hda: WDC WD400BB-00AUA1, ATA DISK drive
hdb: WDC WD400BB-32AUA1, ATA DISK drive
hdc: CREATIVE DVD-ROM DVD6240E, ATAPI CD/DVD-ROM drive
hdd: KENWOOD CD-ROM UCR-421 V212G, ATAPI CD/DVD-ROM drive
hde: Maxtor 91024U4, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xd400-0xd407,0xd802 on irq 10
hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63,
UDMA(100)
hdb: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63,
UDMA(100)
hde: 19999728 sectors (10240 MB) w/2048KiB Cache, CHS=19841/16/63,
UDMA(66)
hdc: ATAPI 24X DVD-ROM drive, 512kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI 68X CD-ROM drive, 512kB Cache, UDMA(33)
Partition check:
 hda: hda1 hda2 hda3 < hda5 hda6 >
 hdb: hdb1
 hde: [PTBL] [1244/255/63] hde1 < hde5 hde6 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.10d
Non-volatile memory driver v1.1
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
<saw@saw.sw.com.sg> and others
PCI: Found IRQ 11 for device 00:0e.0
eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:A0:C9:C8:E4:E9, IRQ
11.
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 668081-004, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x3c15c8f1).
  Receiver lock-up workaround activated.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 188k freed
VFS: Disk change detected on device ide1(22,0)
VFS: Disk change detected on device ide1(22,64)
 

/proc/cpuinfo
=============
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 4
model name      : AMD Athlon(tm) Processor
stepping        : 2
cpu MHz         : 993.350
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips        : 1979.18

==================

  Please let me know if you have any other insights.  I was planning on
now investigating WHY MMX/K7 + 3DNOW is causing this.

  Thanks,
  Seth