Kernel panic

A kernel panic (sometimes abbreviated as KP^[1]) is a safety measure taken by an operating system's kernel upon detecting an internal fatal error in which either it is unable to safely recover or continuing to run the system would have a higher risk of major data loss. The term is largely specific to Unix and Unix-like systems. The equivalent on Microsoft Windows operating systems is a stop error, often called a "blue screen of death (BSOD)".

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.^[2] 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 kernel space. For example, many Unix operating systems panic if the init process, which runs in user space, terminates.^[3][4]

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.^[5] 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.'"^[6]

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. 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. If the system is in an unstable state, rather than risking security breaches and data corruption, the operating system stops in order to prevent further damage, which helps to facilitate diagnosis of the error and may restart automatically.^[7] After recompiling a kernel binary image from source code, a kernel panic while booting the resulting kernel is a common problem if the kernel was not correctly configured, compiled or installed.^[8] 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.^[9] A kernel may also go into panic() if it is unable to locate a root file system.^[10] During the final stages of kernel userspace initialization, a panic is typically triggered if the spawning of init fails. A panic might also be triggered if the init process terminates, as the system would then be unusable.^[11]

The following is an implementation of the Linux kernel final initialization in kernel_init():^[12]

static int __ref kernel_init(void *unused)
{

         ...

        /*
         * 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) {
                if (!run_init_process(execute_command))
                        return 0;
                pr_err("Failed to execute %s.  Attempting defaults...\n",
                        execute_command);
        }
        if (!run_init_process("/sbin/init") ||
            !run_init_process("/etc/init") ||
            !run_init_process("/bin/init") ||
            !run_init_process("/bin/sh"))
                return 0;

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

Operating system specifics

Linux

See also: kdump (Linux)

The Linux kernel implemented a rudimentary panic() function from the beginnings, with the original implementation of version 0.01 simply being: ^[13]

volatile void panic(const char * s)
{
	printk("Kernel panic: %s\n\r",s);
	for(;;);
}

Since then, however, the panic routine has become more and more sophisticated as the kernel itself has evolved.

As of Linux 6.10, a new feature called drm_panic was merged, allowing DRM drivers to support drawing a BSOD-style panic screen to inform the user that a panic occurred. This allows a panic screen to appear even when a display server was running when the panic occurred.^[14]

As of Linux 6.12, drm_panic was extended where the stack trace can be encoded as a QR code.^[15]

Currently, the three alternatives are user (the default), kmesg (the old style) and QR code.^[16]

• 
  Kernel panic with drm_panic enabled
• 
  Kernel panic as seen on an iKVM console
• 
  Kernel panic with drm_panic enabled supporting logging to QR codes

Kernel panics appear in Linux like in other Unix-like systems; however, serious but non-fatal errors can generate another kind of error condition, known as a kernel oops.^[17] 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.

On Linux, a kernel panic causes keyboard LEDs to blink as a visual indication of a critical condition.^[18]

See also

Wikimedia Commons has media related to Kernel panic.

• Core dump
• Blue screen of death
• Fatal system error
• Screen of death
• Machine-check exception (MCE)
• Reliability, availability and serviceability (RAS)

References