A kernel panic is an action taken by an operating system upon detecting an internal fatal error
from which it cannot safely recover.
The term is largely specific to Unix and Unix-like systems; for Microsoft Windows operating systems
the equivalent term is "stop error".
The kernel routines that handle panics, known as panic() in AT&T-derived and BSD Unix source
code, are generally designed to output an error message to the console, dump an image
of kernel memory to disk for post-mortem debugging and then either wait for the system to be
manually rebooted, or initiate an automatic reboot.
The information provided is of a highly technical nature and aims to assist a system administrator
or software developer in diagnosing the problem.
Kernel panics can also be caused by errors originating outside of kernel space.
For example, many Unix OSes panic if the init process, which runs in userspace, terminates.
History The Unix kernel maintains internal consistency
and runtime correctness with assertions as the fault detection mechanism.
The basic assumption is that the hardware and the software should perform correctly
and a failure of an assertion results in a panic, i.e. a voluntary halt to all system
activity.
The kernel panic was introduced in an early version of Unix and demonstrated a major difference
between the design philosophies of Unix and its predecessor Multics.
Multics developer Tom van Vleck recalls a discussion of this change with Unix developer
Dennis Ritchie:
I remarked to Dennis that easily half the code I was writing in Multics was error recovery
code.
He said, "We left all that stuff out.
If there's an error, we have this routine called panic, and when it is called, the machine
crashes, and you holler down the hall, 'Hey, reboot it.'"
The original panic() function was essentially unchanged from Fifth Edition UNIX to the VAX-based
UNIX 32V and output only an error message with no other information, then dropped the
system into an endless idle loop.
Source code of panic() function in UNIX V6:
As the Unix codebase was enhanced, the panic() function was also enhanced to dump various
forms of debugging information to the console.
Causes A panic may occur as a result of a hardware
failure or a software bug in the operating system.
In many cases, the operating system is capable of continued operation after an error has
occurred.
However, the system is in an unstable state and rather than risking security breaches
and data corruption, the operating system stops to prevent further damage and facilitate
diagnosis of the error and, in usual cases, restart.
After recompiling a kernel binary image from source code, a kernel panic during booting
the resulting kernel is a common problem if the kernel was not correctly configured, compiled
or installed.
Add-on hardware or malfunctioning RAM could also be sources of fatal kernel errors during
start up, due to incompatibility with the OS or a missing device driver.
A kernel may also die with a panic message if it is unable to locate a root file system.
During the final stages of kernel userspace initialization, a panic is typically triggered
if the spawning of init fails, as the system would then be unusable.
The following is an implementation of the Linux kernel final initialization in kernel_init():
Operating-system-dependent details Linux
Kernel panics appear in Linux like other Unix-like systems, but they can also generate another
kind of error condition, known as a kernel oops.
In this case, the kernel normally continues to run after killing the offending process.
As an oops could cause some subsystems or resources to become unavailable, they can
later lead to a full kernel panic.
Mac OS X When a kernel panic occurs in Mac OS X 10.2
through 10.7, the computer displays a multilingual message informing the user that they need
to reboot the system.
Prior to 10.2, a more traditional Unix-style panic message was displayed; in 10.8 and later,
the computer automatically reboots and displays a message after the restart.
The format of the message varies from version to version:
10.0 - 10.1: The system displays text detailing the error on-screen and then the system becomes
unresponsive.
10.2: Displays a message on a white background informing the user that they should restart
the computer.
The message is shown in 4 languages: English, French, German and Japanese.
10.3 – 10.5: The kernel panic is almost the same as version 10.2 but the background
of the error screen is black.
10.6 – 10.7: The text has been revised and now includes a Spanish translation.
10.8 and later: The computer may appear to freeze, then always immediately reboots, and
when starting back up, it shows a warning for a few seconds about the computer restarting
because of a problem, and then the computer starts up.
A Chinese translation was also added.
Sometimes when there are five kernel panics within three minutes of the first one, the
Mac will display a prohibitory sign for 30 seconds, and then shut down.
In all versions above 10.2, the text is in superimposed on a standby symbol and is not
full screen.
Debugging information is saved in NVRAM and written to a log file on reboot.
In 10.7 there is a feature to automatically restart after a kernel panic.
In some cases, on 10.2 and later, white text detailing the error may appear in addition
to the standby symbol.
See also Fatal system error
Core dump References