Messages in this thread | | | Date | Wed, 30 Jun 1999 21:39:20 -0700 | From | Nate Eldredge <> | Subject | Re: 2.2.10 oops (finally, something I can report!) |
| |
Linus wrote: > > In article <Pine.LNX.4.05.9906300304020.7161-100000@vitelus.com>, > Aaron Lehmann <aaronl@vitelus.com> wrote: > >This time I had the fortune of an Oops that didnt lock up the machine. I'm > >going to apply KMSGDUMP so I can send all future oopses also. > > > >I hope this helps fix the stability problems: > > > >Reading Oops report from the terminal > > Interesting. > > The oops looks fine. The symbolic information also looks fine: the code > in question does in fact look like it is the second instruction in > "inet_sendmsg()". Everything basically seems to say that the oops is > correctly decoded and caught. > > The thing that does NOT make sense is the cause of the oops itself, > though. > > The oops happens on > > c017b651 pushl %ebx > > and %esp = c3941e80. > > And quite frankly, there's not a way in h*ll that that instruction could > raise the exception in question. But it does. > > I would _strongly_ suspect one of two things: > - bad CPU. > - bad cache or RAM timings.
I had a Cyrix CPU some time back that had a *very* similar problem. I believe it was running 2.0.36. Anyway, it worked absolutely fine, until one day I built EGCS. This binary would, about 1/3 of the time, crash. Poking around with a debugger showed that the instruction on which it crashed was an access to a perfectly valid address (according to /proc/xx/maps). Swapping in a different CPU (I think it was an Intel Pentium) fixed it. ISTR it also could be fixed by turning off the L1 cache or something equally unacceptable performance-wise.
Here is its /proc/cpuinfo. It was a 110 MHz (aka "133+") 6x86.
processor : 0 cpu : 586 model : 6x86 vendor_id : CyrixInstead stepping : 2.5, core/bus clock ratio: 2x fdiv_bug : no hlt_bug : no f00f_bug : no fpu : yes fpu_exception : yes cpuid : yes wp : yes flags : fpu bogomips : 110.18
In short, I think the CPU may well be a reasonable suspect. I'd suggest replacing it, if you can beg, borrow, or steal another (a different brand might be wise), and see if there is any change.
HTH, --
Nate Eldredge nate@cartsys.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |