Re: Finding mysterious 2.0.33 crashes

Doug Ledford (dledford@dialnet.net)
Sun, 15 Feb 1998 10:33:12 -0600

Manfred Petz wrote:
>
> > Has anyone had mysterious hangups in 2.0.33 (total hang, no messages in
> > logs, no oops) who is _not_ using an Adaptec SCSI driver? It could help
> > narrow the range of code to be checked if that's a common factor in all
> > these cases. Also, has anyone had this problem who is _not_ using an
> > NE2000 ethernet card? Who is _not_ using a PS/2 mouse? Who is _not_
> > using glibc?
> >
> > Let's try to figure out the commonalities of our systems. My first
> > suspicion is the 2940 driver.
> >
>
> Here I'm running 6 Linux servers with *identical* hardware:
>
> o quite old HP-Vectras with AMD P5
> o 3c509
> o 1x Quantum IDE (onboard controller)
> o memory ranging from 16MB to 48MB (that's the only
> difference in hardware)
> o there's an onboard PS/2 but there's no mouse.
>
> no other special hardware
> *identical* kernel (I build it once for all systems)
>
> all machines but two of them now run 2.0.33 for weeks, before I used
> 2.0.31 (with great success, one server actually runs 2.0.31 for 90 days now).
>
> But here's my problem:
>
> ONE machine runs 2.0.31 very fine (for months!). Someday I decided to
> upgrade to 2.0.32. It then *repeatedly* crashed after at most 2 days of
> uptime. 2.0.33 same story. Absolutely dead, no oops, no syslog entry.
> I tried this multiple times.
>
> It seems to me that there must have happened something between 2.0.31
> and 2.0.32.

Well, the only thing that's really been established in this thread so far is
that there is no one common device in all of these machines except maybe a 3
1/2" floppy or something similarly innane.

OK..I know this isn't an answer, but a complete lack of commonality always
brings me back to this point. Manfred commented that something must have
changed between 2.0.31 and 2.0.33. Well, of course that's a given.
However, people sometimes seem to forget that changed items can have more
impact than just bugs in the code. Changed items can also mean better
performance (reference the 1.2.13-LMP kernel, which included performance
enhancements to the string.h include file, which is pretty universal in
kernel impact). Better performance can mean that more hardware that was
just barely getting by before actually shows up as being marginal and
faulty. So, whenever a new kernel starts causing totally unrelated problems
such as this (and especially in something like Manfred's configuration with
only a few out of many identical machines effected), a person should never
over look the old standby of checking their hardware. Also don't forget,
that the problem could be one that isn't transient, meaning it might not
just go away by changing a BIOS value. It is entirely possible that the
faulty hardware could get replaced and the problem remain if the faulty
hardware caused corruption on the disk or caused the kernel compile to be
buggy (here I reference my old AMD 5x86 processor upgraded 486 machine, it
wouldn't boot with a new kernel, I put in a genuine Intel CPU and it still
wouldn't boot the new kernel, then I recompiled the kernel with the genuine
Intel CPU and viola, it suddenly booted fine). So, to those people that
have been having these problems, please do a hardware check to make sure
things are OK, including slowing down RAM or what ever might be appropriate
on your machine, and try doing a make clean && make zlilo process after
having slowed things down and being reasonably sure that everything is
currently running hunky-dory.

-- 


 Doug Ledford  <dledford@dialnet.net>
  Opinions expressed are my own, but
     they should be everybody's.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu