Messages in this thread | | | Date | Sun, 15 Feb 1998 10:33:12 -0600 | From | Doug Ledford <> | Subject | Re: Finding mysterious 2.0.33 crashes |
| |
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
| |