the Linux Place on the Net

Linux kernel panic

By Wikipedia, the free encyclopedia

A kernel panic message is displayed by an operating system upon detecting an internal system error from which it cannot recover.
A kernel panic message
is displayed by an operating
system upon detecting an internal
system error from which it
cannot recover.

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 "Bug check" (or, colloquially, "Blue Screen of Death").

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 highly technical nature and aims to assist a system administrator or software developer in diagnosing the problem.


The Unix kernel maintains internal consistency and runtime correctness with assertions as fault detection mechanism. The basic assumption is that the hardware and the software should perform correctly and a failure of an assertion results 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:

 * In case console is off,
 * panicstr contains argument to last
 * call to panic.
 char    *panicstr;

  * Panic is called on unresolvable
  * fatal errors.
  * It syncs, prints "panic: mesg" and
  * then loops.
 char *s;

        panicstr = s;
        printf("panic: %s\n", s);


As the Unix codebase was enhanced, the panic() function was also enhanced to dump various forms of debugging information to the console.


A panic may occur as a result of a hardware failure or a bug in the operating system. In many cases, the operating system could continue 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.

After recompiling a Unix or Linux kernel binary image from source code, a kernel panic during booting the resulting kernel is a common and annoying problem if the kernel was not configured, compiled or installed correctly. Add-on hardware or malfunctioning RAM could also be a source of fatal kernel errors during start up, due to incompatibility with the OS or a missing device driver. A kernel may also die with panic message if it is unable to locate a root file system. During final stages of kernel userspace initialization, a panic is triggered if the spawning of init fails, since the system becomes unusable.

The following is an implementation of the Linux kernel final initialization in init_post():

static noinline int init_post(void)

          * We try each of these until one succeeds.
          * The Bourne shell can be used instead of init if we are
          * trying to recover a really broken machine.
         if (execute_command) {

                 printk(KERN_WARNING "Failed to execute %s.  Attempting "
                                         "defaults...\n", execute_command);


         panic("No init found.  Try passing init= option to kernel. "
               "See Linux Documentation/init.txt for guidance.");



Kernel panics appear in Linux like other Unix-like systems, but 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

Mac OS X 10.6 kernel panic.
Mac OS X 10.6 kernel panic.

Kernel panics also appear in Mac OS X. These can happen while booting up or when using an application. When one occurs, the computer displays a multilingual message informing the user that they need to reboot the system. The format varies from version to version:

  • 10.0, 10.1: The system prints text detailing the error on-screen and then the system becomes unresponsive.

  • 10.2: Similar to the current versions of the kernel panic except the text is more spaced out and the background is white.

  • 10.3 - 10.5: The background is now black, but with the same language translations and the same text as version 10.2.

  • 10.6 - 10.7: The text is different and now includes a Spanish translation.

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.


Published - October 2011

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.

Read all articles at the Linux Place!