Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

What does it mean when your computer has a "kernel panic"?

Does it equate to the windows BsoD?

Also, what methods, tips, tricks are available to the user when a kernel panic strikes?

share|improve this question
2  
A kernel panic is better than a BSOD because its name implies what the user should do when it happens. –  amphetamachine Feb 4 '11 at 18:44
    
A windows blue also gives some info, tho it's not so much helpful most of the time. –  ott-- May 10 '13 at 16:53
add comment

3 Answers 3

up vote 12 down vote accepted

Kernel panic is the same as BSOD and is non-rescuable IIRC. However smaller failure is OOPS which denotes some error in kernel.

  1. You can use kexec which switches to new kernel on panic (you can threat it as fast reboot) - possibly getting meaningful dump of system to debug the problem
  2. You can use panic parameter which reboots kernel after n seconds. You can instruct GRUB to switch to fallback kernel in such case
  3. Use Magic SysRQ keys to print stack traces etc.
share|improve this answer
5  
More correct a BSOD is a KP with a really bad error message screen. –  xenoterracide Sep 8 '10 at 5:28
    
The most notable magic SysRq was the emergency sync to flush the buffers (when it still possible). –  ott-- May 10 '13 at 16:57
add comment

It is the unexpected program flow behavior (kernel is a program in this case). In case of panic program stops working. It IS equal to the windows BsoD. KP means something wrong with kernel or modules. If it's stable kernel - look at drivers. If nothing special and all drivers are common it could be hardware problem.

share|improve this answer
    
or kernel goes picnic.. –  uray Sep 6 '10 at 14:53
    
Even in a stable kernel, there are always some bugs left. –  ott-- May 10 '13 at 16:59
add comment

A Linux kernel panic is a subroutine call that the kernel executes when the kernel logic determines that a condition exists that makes continued execution of the normal logic impossible or irresponsible.

The kernel can call a panic when:

  1. It detects a software error in the kernel code or stack
  2. When there is a run-time condition such as out-of-memory with no killable processes
  3. A CPU exception during privileged mode execution results in an oops condition

There are about 950 distinct conditions where a panic is called in the 3.X kernels. The panic subroutine first prints the kernel stack dump and CPU registers to the console. Then, if a crash kexec kernel has been configured, it boots the kexec kernel. Otherwise the panic routine busts all spinlocks and performs an emergency restart.

An oops is a subroutine called from a CPU exception handler for a CPU exception that occurs while executing in privileged (i.e kernel) mode. The exception can occur as a result of an error in kernel code, or because of a hardware failure, or as the result of an external condition that causes a specific exception. The handler for the exception prints a kernel log with CPU registers and modules list. Unlike panic calls, the kernel logic itself never calls an oops outside the context of CPU exception handlers.

If the kernel is configured for kexec, then an oops will result in the kexec kernel being booted. Otherwise, if the exception occurs while executing an interrupt handler, then the oops results in a kernel panic call. Otherwise, if the kernel is is configured with “panic on oops”, then the oops will result in a panic call. Otherwise the the kernel exits the exception handler and resumes execution. When the kernel exits the exception handler and resumes execution, the integrity of the kernel is suspect.

CPU exception handlers are architecture-specific. They are usually implemented in arch/*/kernel/traps.c, and set in the architecture-specific kernel entry code that sets up the interrupt table. See for example arch/powerpc/kernel/traps.c and arch/powerpc/kernel/head_fsl_booke.S.

Both kernel panic and oops conditions can be configured to call a kmsg_dump routine that you can use to save crash debugging information to RAM, or to flash memory unless the oops occurred in interrupt context, in which case the “kmsg_dump” routine can only be used to save to RAM, not to MTD. When saving to RAM, it is your responsibility to a) ensure that the RAM area used is not overwritten during kexec boot or emergency restart boot, and b) to harvest the memory area from the kexec kernel or from the boot loader logic.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.