[aclug-L] Re: kernel panic question

[Jonathan Hall <jonhall@xxxxxxxxxxxx>]

Kernel panics often (but not always) will lock the computer--it depends on
the sevarity of the problem... or more accurately "where" the problem
happened.

If it happened in a non-critical process, it probably won't lock the system.

A kernel panic will usually happen as the result of a bug in the kernel
or hardware failure... I've had kernel panics happen with bad network cards,
bad RAM, overheating CPU, bad hard disk, etc...

I've never had it happen as the result of a kernel bug, AFAIK (altho I have
had it happen as the result of some third-party kernel module bugs).... 
'course if you're running a development kernel, you're more likely to run
into kernel panics as a direct result of kernel bugs, too :-)


On Fri, Jul 21, 2000 at 11:57:59AM -0500, Tom Hull wrote:
> John Reinke wrote:
> > 
> > I was just downloading a rather large file (117 MB), and this suddenly
> > appeared:
> > 
> > Message from syslogd@jupiter at Fri Jul 21 11:06:45 2000 ...
> > jupiter kernel: Kernel panic: VFS: LRU block list corrupted
> 
> This call/message is from fs/buffer.c. The LRU list is double-linked,
> and one or more links have invalid data, so memory corruption is
> indicated.
> 
> > 1) How serious is a kernel panic? I stopped the download after about 20 MB,
> > but didn't know if it is just a little warning, or if things are at DEFCON
> > 1 and the system is about to crash.
> 
> Kernel panics occurs when the kernel detects something insane, and decides
> that death is preferable to madness. See kernel/panic.c. So the answer to
> "how serious?" is extremely.
> 
> However, it sounds like you were still running, so maybe the kernel panic
> message came from some other machine? The message normally goes to system
> console (usually /dev/console).
> 
> > 2) Where can I go to learn about kernel panics and fixing whatever caused 
> > it?
> 
> Not sure. I'd expect something about this in a Kernel-Hackers-HOWTO or some
> such similar documents. Source code, of course. My understanding is that
> Linux kernel debugging tools are primitive (relative to other Unix; i.e.,
> no standard kdb or crash). In any case, debugging kernel is difficult,
> debugging memory corruption is difficult, debugging both is worse. But
> I'd like to know more, myself.
> 
> > Thanks,
> > John
> > 
> > -- This is the discussion@xxxxxxxxx list.  To unsubscribe,
> > visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi
> 
> -- 
> /*
>  *  Tom Hull * thull@xxxxxxxxxxx * http://www.ocston.org/~thull/
>  */
> 
> -- This is the discussion@xxxxxxxxx list.  To unsubscribe,
> visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi

--
Floppy disk tip #2: Diskettes should be cleaned and waxed once a week. 
Microscopic metal particles may be removed by waving a powerful magnet over
the surface of the disk.  Any stubborn metal shavings can be removed with
scouring powder and steel wool.  When waxing a diskette, make sure the
surface is even.  This will allow the diskette to spin faster, resulting in
better access time.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Jonathan Hall  *  jonhall@xxxxxxxxxxxx  *  PGP public key available
 Systems Admin, Future Internet Services; Goessel, KS * (316) 367-2487
         http://www.futureks.net  *  PGP Key ID: FE 00 FD 51
                  -=  Running Debian GNU/Linux  =-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-- This is the discussion@xxxxxxxxx list.  To unsubscribe,
visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi