A kernel panic is the most serious form of computer crash. It occurs when the OS kernel detects an internal inconsistency or error that cannot be automatically resolved. Since there is no way for the kernel to reliably request human intervention in these matters, it `panics' and immediately interrupts the normal operation of the computer. What happens next depends on the kernel. Linux throws debugging information onto the screen and waits for a reboot. BeOS and NetBSD dump the user into the kernel debugger, which for the average user is equivalent to the Linux behavior. Windows NT displays the dreaded Blue Screen of Death. The only thing all kernel panics have in common is that the only way to restore normal functionality is to reboot. The actual term `kernel panic' is normally only heard in the context of Unix and Unix-like systems; other systems have other terms for what is essentially the same thing.

There are several ways a kernel panic may be caused. One of the most common is bad hardware. If kernel memory is corrupted by a hardware fault, the kernel will likely panic. Kernel bugs can also cause panics, but bugs that are severe enough to cause panics should not be found in stable kernel versions, and even in beta kernels they should be rare. Panics can also occur during the boot sequence, if the conditions for a successful boot are not met. Under *nix systems the most common of these cases is if the root filesystem is for some reason not mountable. In particular, if the root filesystem is remote and the connection times out, the kernel will panic. Also, if init is not found on the root filesystem, the kernel will panic.

Now, here are some specifics dredged from the Linux 2.4.19 source through the wonderful LXR system. The Linux kernel defines the mechanism for a panic as a function panic() in kernel/panic.c. 416 other source files in 2.4.19 then contain calls to panic(). Here's why kernel subsystems panic:

In general the use of panics in the Linux kernel is very defensive, intended to prevent possibly dangerous kernel glitches from trashing the system.


(CC)
This writeup is copyright 2002-2004 D.G. Roberge and is released under the Creative Commons Attribution-NonCommercial-ShareAlike licence. Details can be found at http://creativecommons.org/licenses/by-nc-sa/2.0/ .

Log in or registerto write something here or to contact authors.