Kernel Panics

From ArchWiki
Revision as of 20:35, 8 October 2017 by Mcnster (talk | contribs) (Reboot: Deleted section.)
Jump to: navigation, search

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: Last major update to this page was November 2009. (Discuss in Talk:Kernel Panics#)

Merge-arrows-2.pngThis article or section is a candidate for merging with General troubleshooting.Merge-arrows-2.png

Notes: If you remove all the excess verbosity and duplicate instructions, a few paragraphs remain which can go to General troubleshooting (Discuss in Talk:Kernel Panics#)

A kernel panic occurs when the Linux kernel enters an unrecoverable failure state. The state typically originates from buggy hardware drivers resulting in the machine being deadlocked, non-responsive, and requiring a reboot. Just prior to deadlock, a diagnostic message is generated, consisting of: the machine state when the failure ocurred, a call trace leading to the kernel function that recognized the failure, and a listing of currently loaded modules. Thankfully, kernel panics don't happen very often using mainline versions of the kernel--such as those supplied by the official repositories--but when they do happen, you need to know how to deal with them.

Note: Kernel panics are sometimes referred to as oops or kernel oops. While both panics and oops occur as the result of a failure state, an oops is more general in that it does not necessarily result in a deadlocked machine--sometimes the kernel can recover from an oops by killing the offending task and carrying on.
Tip: Pass the kernel parameter oops=panic at boot or write 1 to /proc/sys/kernel/panic_on_oops to force a recoverable oops to issue a panic instead. This is advisable is you are concerned about the small chance of system instability resulting from an oops recovery which may make future errors difficult to diagnose.