本文详细介绍了内核错误(Kernel panic)的概念，包括其定义、触发原因及如何收集关键信息进行故障排查。同时，针对hard panic与soft panic的不同特点进行了对比，并提供了实际案例分析。 摘要生成于 ，由 DeepSeek-R1 满血版支持， (Kernel panic) 是指操作系统在监测到内部的致命错误，并无法安全处理此错误时采取的动作。一旦到这个情况， kernel 就尽可能把它此时能获取的全部信息都打印出来，至于能打印出多少信息，那就看是哪种情况导致它 panic 了。 这个概念主要被限定在 Unix 以及类 Unix 系统中；对于 Microsoft Windows 系统，等同的概念通常被称为蓝屏死机。

操作系统内核中处理 Kernel panic 的子程序（在 AT&T 派生类以及 BSD 类 Unix 中，通常称为 panic() ）通常被设计用来向控制台输出错误信息，向磁盘保存一份内核内存的转储，以便事后的调试，然后等待系统被手动重新引导，或自动重新引导。该程序提供的技术性信息通常是用来帮助系统管理员或者软件开发者诊断问题的。

操作系统试图读写无效或不允许的内存地址是导致内核错误的一个常见原因。内核错误也有可能在遇到硬件错误或操作系统 BUG 时发生。在许多情况中，操作系统可以在内存访问违例发生时继续运行。然而，系统处于不稳定状态时，操作系统通常会停止工作以避免造成破坏安全和数据损坏的风险，并提供错误的诊断信息。内核错误在早期的 Unix 系统中被引入，显示了在 Unix 与 Multics 在设计哲学上的主要差异之一。 Multics 的开发者 Tom van Vleck 曾引述了一段在这个问题上与 Unix 开发者 Dennis Ritchie 的讨论：

我提醒 Dennis 说，我在 Multics 中写的近半数代码都是错误恢复代码。 他说：“我们不需要这些。我们有称为 panic 的子程序，如果发生了错误就可以调用这个函数，使得系统崩溃， 然后你可以在大厅里面大叫：‘嘿，重启机器’。”

原始的 panic() 函数从 UNIX 第五版开始到基于 VAX 的 UNIX 32V 期间几乎没有变化，只是输出一条错误信息，然后就使系统进入 NOP 的死循环中。当改进 UNIX 的基础代码的时候， panic() 函数也有所改进，可以向控制台输出多种格式的调试信息。

kernel panic 主要有以下几个出错提示：

Kernel panic - not syncing fatal exception in interrupt

kernel panic - not syncing: Attempted to kill the idle task!

kernel panic - not syncing: killing interrupt handler!

Kernel Panic - not syncing ： Attempted to kill init!

2.什么能导致 kernel panic ：

一般出现下面的情况，就认为是发生了 kernel panic:

• 机器彻底被锁定 ， 不能使用

• 数字键 (Num Lock) ， 大写锁定键 (Caps Lock) ， 滚动锁定键 (Scroll Lock) 不停闪烁 。

• 如果在终端下 ， 应该可以看到内核 dump 出来的信息 （ 包括一段 ” Aieee” 信息或者 ” Oops” 信息 ）

• 和 Windows 蓝屏相似

有两种主要类型 kernel panic ：

hard panic( 也就是 Aieee 信息输出 )

soft panic ( 也就是 Oops 信息输出 )

只有 加载到内核空间的驱动模块 才能 直接 导致 kernel panic ，你可以在系统正常的情况下，使用 lsmod 查看当前系统加载了哪些模块。 除此之外， 内建在内核里的组件 （比如 memory map 等）也能导致 panic 。因为 hard panic 和 soft panic 本质上不同，因此我们分别讨论。

2.1 hard panic

对于 hard panic 而言，最大的可能性是驱动模块的中断处理 (interrupt handler) 导致的 ，一般是因为驱动模块在中断处理程序中访问一个空指针 (null pointre) 。一旦发生这种情况，驱动模块就无法处理新的中断请求，最终导致系统崩溃。

例如：在多核系统中，包括 AP 应用处理器、 mcu 微控制器和 modem 处理器等系统中， mcu 控制器用于系统的低功耗控制， mcu 微控制器由于某种原因超时向 AP 应用处理器发送一个超时中断， AP 接受中断后调用中断处理函数读取 mcu 的状态寄存器，发现是 mcu 的超时中断，就在中断处理程序中主动引用一个空指针，迫使 AP 处理器打印堆栈信息然后重启 linux 系统。这就是一个典型的 hard panic 。

根据 panic 的状态不同，内核将记录所有在系统锁定之前的信息。因为 kenrel panic 是一种很严重的错误，不能确定系统能记录多少信息，下面是一些需要收集的关键信息，他们非常重要，因此尽可能收集全，当然如果系统启动的时候就 kernel panic ，那就无法知道能收集到多少有用的信息了。

1. /var/log/messages : 幸运的时候，整个 kernel panic 栈跟踪信息都能记录在这里。

2. 应用程序 / 库日志 : 可能 可以从这些日志信息里能看到发生 panic 之前发生了什么。

3. 其他发生 panic 之前的信息，或者知道如何重现 panic 那一刻的状态

4. 终端屏幕 dump 信息，一般 OS 被锁定后，复制，粘贴肯定是没戏了，因此这类信息，你可以需要借助数码相机或者原始的纸笔工具了。

实际上，当内核发生 panic 时， linux 系统会默认立即重启系统，当然这只是默认情况，除非你修改了产生 panic 时重启定时时间，这个值默认情况下是 0 ，即立刻重启系统。所以当 panic 时没有把 kernel 信息导入文件的话，那么可能你很难再找到 panic 产生的地方。

Linux 的稳定性勿容置疑，但是有些时候一些 Kernel 的致命错误还是会发生（有些时候甚至是因为硬件的原因或驱动故障）， Kernel Panic 会导致系统 crash ，并且默认的系统会一直 hung 在那里，直到你去把它重新启动！ 不过你可以在 /etc/sysctl.conf 文件中加入

2.2 soft panic(oops)

在 Linux 上， oops 即 Linux 内核的行为不正确，并产生了一份相关的错误日志。 许多类型的 oops 会导致 kernel panic ，即令系统立即停止工作，但部分 oops 也允许继续操作，作为与稳定性的妥协。这个概念只代表一个简单的错误。

当内核检测到问题时，它会打印一个 oops 信息然后终止全部相关进程。 oops 信息可以帮助 Linux 内核工程师调试，检测 oops 出现的条件，并修复导致 oops 的程序错误。

Linux 官方内核文档中提到的 oops 信息被放在内核源代码 Documentation/oops-tracing.txt 中。通常 klogd 是用来将 oops 信息从内核缓存中提取出来的，然而，在某些系统上，例如最近的 Debian 发行版中， rsyslogd 代替了 klogd ，因此，缺少 klogd 进程并不能说明 log 文件中缺少 oops 信息的原因。

若系统遇到了 oops ，一些内部资源可能不再可用。即使系统看起来工作正常，非预期的副作用可能导致活动进程被终止。 oops 常常导致 kernel panic ，若系统试图使用被禁用的资源。 Kernelloops 提到了一种用于收集和提交 oops 到 http://www.kerneloops.org/ 的软件 。 Kerneloops.org 同时也提供 oops 的统计信息。

1. 没有 hard panic 严重

2. 通常导致段错误 (segmentation fault)

3. 可以看到一个 oops 信息， /var/log/messages 里可以搜索到’ Oops’

4. 机器稍微还能用（但是收集信息后，应该重启系统）

凡是非中断处理引发的模块崩溃都将导致 soft panic 。 在这种情况下，驱动本身会崩溃，但是还不至于让系统出现致命性失败，因为它没有锁定中断处理例程。 导致 hard panic 的原因同样对 soft panic 也有用（比如在运行时访问一个空指针）

信息收集：

当 soft panic 发生时，内核将产生一个包含内核符号 (kernel symbols) 信息的 dump 数据 ，这个将记录在 /var/log/messages 里。为了开始排查故障，可以使用 ksymoops 工具来把内核符号信息转成有意义的数据。

为了生成 ksymoops 文件 , 需要：

从 /var/log/messages 里找到的堆栈跟踪文本信息保存为一个新文件。确保删除了时间戳 (timestamp) ，否则 ksymoops 会失败。

运行 ksymoops 程序（如果没有，请安装）

详细的 ksymoops 执行用法，可以参考 ksymoops(8) 手册。

3.Kernel panic 实例:

今天就遇到 一个客户机器内核报错：“ Kernel panic-not syncing fatal exception” ，重启后正常，几个小时后出现同样报错，系统 down 了，有时重启后可恢复有时重启后仍然报同样的错误。

什么是 fatal exception?

“ 致命异常（ fatal exception ）表示一种例外情况，这种情况要求导致其发生的程序关闭。通常，异常（ exception ）可能是任何意想不到的情况（它不仅仅包括程序错误）。致命异常简单地说就是异常不能被妥善处理以至于程序不能继续运行。

软件应用程序通过几个不同的代码层与操作系统及其他应用程序相联系。当异常（ exception ）在某个代码层发生时，为了查找所有异常处理的代码，各个代码层都会将这个异常发送给下一层，这样就能够处理这种异常。如果在所有层都没有这种异常处理的代码，致命异常（ fatal exception ）错误信息就会由操作系统显示出来。这个信息可能还包含一些关于该致命异常错误发生位置的秘密信息（比如在程序存储范围中的十六进制的位置）。这些额外的信息对用户而言没有什么价值，但是可以帮助技术支持人员或开发人员调试程序。

当致命异常（ fatal exception ）发生时，操作系统没有其他的求助方式只能关闭应用程序，并且在有些情况下是关闭操作系统本身。 当使用一种特殊的应用程序时，如果反复出现致命异常错误的话，应将这个问题报告给软件供应商。 ” 而且此时键盘无任何反应，必然使用 reset 键硬重启。

处理 panic 后的系统自动重启 panic.c 源文件有个方法，当 panic 挂起后，指定超时时间，可以重新启动机器，这就是前面说的 panic 超时重启。

# vi linux-2.6.31.8/kernel/panic.c ...

if (panic_timeout > 0) {

* Delay timeout seconds before rebooting the machine.

* We can't use the "normal" timers since we just panicked.

int i;

printk(KERN_EMERG "Rebooting in %d seconds..", panic_timeout);

for (i = 0; i < panic_timeout*1000; ) {

touch_nmi_watchdog();

i += panic_blink(i);

mdelay(1);

* This will not be a clean reboot, with everything

* shutting down. But if there is a chance of

* rebooting the system it will be rebooted.

emergency_restart();

} ...

修改方法：

/etc/sysctl.conf 文件中加入

kernel.panic = 30 #panic 错误中自动重启，等待时间为 30 秒

kernel.sysrq=1 # 激活 Magic SysRq ！ 否则，键盘鼠标没有响应

设置 kernel.sysrq=1 使得鼠标键盘有反应了之后按住 [ALT]+[SysRq]+[COMMAND], 这里 SysRq 是 Print SCR 键，而 COMMAND 按以下来解释 :

b – 立即重启
e – 发送 SIGTERM 给 init 之外的系统进程
o – 关机
s – sync 同步所有的文件系统
u – 试图重新挂载文件系统

很多网友安装 linux 出现“ Kernel panic-not syncing fatal exception in interrupt” 是由于网卡驱动原因。解决方法：将选项“ Onboard Lan” 的选项“ Disabled”, 重启从光驱启动即可。等安装完系统之后，再进入 BIOS 将“ Onboard Lan” 的选项给“ enable” ，下载相应的网卡驱动安装。

如出现以下报错：

init() r8168 …

… ： Kernel panic: Fatal exception

r8168 是网卡型号。

在 BIOS 中禁用网卡，从光驱启动安装系统。再从网上下载网卡驱动安装。

#tar  vjxf  r8168-8.014.00.tar.bz2

# make  clean  modules       (as root or with sudo)

# make  install

# depmod  -a

# modprobe  r8168

安装好系统后 reboot 进入 BIOS 把网卡打开。

另有网友在 Kernel panic 出错信息中看到“ alc880” ，这是个声卡类型。尝试着将声卡关闭，重启系统，搞定。

安装 linux 系统遇到安装完成之后，无法启动系统出现 Kernel panic-not syncing fatal exception 。很多情况是由于板载声卡、网卡、或是 cpu 超线程功能（ Hyper-Threading ）引起的。这类问题的解决办法就是先查看错误代码中的信息，找到错误所指向的硬件，将其禁用。系统启动后，安装好相应的驱动，再启用该硬件即可。

另外出现 “ Kernel Panic — not syncing: attempted to kill init” 和“ Kernel Panic — not syncing: attempted to kill idle task” 有时把内存互相换下位置或重新插拔下可以解决问题。

还有一种情况， swap 交换分区没有配置的时候，也会出现” kernel panic – not syncing : attempted to kill init” ，已在 RHEL6.2_64bit 上测试。

参考 ： http://blog.csdn.net/ylyuanlu/article/details/9115159

http://wiki.linuxdeepin.com/index.php?title=Linux_kernel_panic&oldid=7764

http://www.vpsee.com/2010/08/reboot-linux-after-a-kernel-panic/

http://www.4byte.cn/question/721620/how-to-detect-a-kernel-panic-on-a-remote-machine.html