Linux内核Kernel panic常见问题（详细）总结

一、简介

本文主要总结linux系统触发Kernel panic的常见报错总结。
Kernel panic它表示Linux kernel走到了一个不知道该怎么走下一步的状况，一旦到这个情况，kernel就尽可能把它此时能获取的全部信息都打印出来，至于能打印出多少信息，那就看是那种情况导致它panic了。
1.hard panic(也就是Aieee信息输出)
2.soft panic (也就是Oops信息输出)

1.1 hard panic

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

机器彻底被锁定，不能使用
数字键(Num Lock)，大写锁定键(Caps Lock)，滚动锁定键(Scroll Lock)不停闪烁。
如果在终端下，应该可以看到内核dump出来的信息（包括一段”Aieee”信息或者”Oops”信息）
和Windows蓝屏相似

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

信息收集
根据panic的状态不同，内核将记录所有在系统锁定之前的信息。因为kenrel panic是一种很严重的错误，不能确定系统能记录多少信息，下面是一些需要收集的关键信息，他们非常重要，因此尽可能收集全，当然如果系统启动的时候就 kernel panic，那就无法只知道能收集到多少有用的信息了。
/var/log/messages: 幸运的时候，整个kernel panic栈跟踪信息都能记录在这里。
应用程序/库 日志: 可能可以从这些日志信息里能看到发生panic之前发生了什么。
其他发生panic之前的信息，或者知道如何重现panic那一刻的状态
终端屏幕dump信息，一般OS被锁定后，复制，粘贴肯定是没戏了，因此这类信息，你可以需要借助数码相机或者原始的纸笔工具了。

如果kernel dump信息既没有在/var/log/message里，也没有在屏幕上，那么尝试下面的方法来获取（当然是在还没有死机的情况下）：

如果在图形界面，切换到终端界面，dump信息是不会出现在图形界面的，甚至都不会在图形模式下的虚拟终端里。
确保屏幕不黑屏，可以使用下面的几个方法：
setterm -blank 0
setterm -powerdown 0
setvesablank off
从终端，拷贝屏幕信息（方法见上）

完整栈跟踪信息的排查方法
栈跟踪信息(stack trace)是排查kernel panic最重要的信息，该信息如果在/var/log/messages日志里当然最好，因为可以看到全部的信息，如果仅仅只是在屏幕上，那么最上面的 信息可能因为滚屏消失了，只剩下栈跟踪信息的一部分。如果你有一个完整栈跟踪信息的话，那么就可能根据这些充分的信息来定位panic的根本原因。要确认 是否有一个足够的栈跟踪信息，你只要查找包含”EIP”的一行，它显示了是什么函数和模块调用时导致panic。

使用内核调试工具(kenrel debugger ,aka KDB)

如果跟踪信息只有一部分且不足以用来定位问题的根本原因时，kernel debugger(KDB)就需要请出来了。
KDB编译到内核里，panic发生时，他将内核引导到一个shell环境而不是锁定。这样，我们就可以收集一些与panic相关的信息了，这对我们定位问题的根本原因有很大的帮助。

使用KDB需要注意，内核必须是基本核心版本，比如是2.4.18，而不是2.4.18-5这样子的，因为KDB仅对基本核心有效。

1.2 soft panic

症状：
没有hard panic严重
通常导致段错误(segmentation fault)
可以看到一个oops信息，/var/log/messages里可以搜索到’Oops’
机器稍微还能用（但是收集信息后，应该重启系统）

原因：
凡是非中断处理引发的模块崩溃都将导致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)手册。

kernel panic - not syncing : fatal exception的问题
使用内核调试工具(kenrel debugger ,aka KDB)
如果跟踪信息只有一部分且不足以用来定位问题的根本原因时，kernel debugger(KDB)就需要请出来了。
KDB编译到内核里，panic发生时，他将内核引导到一个shell环境而不是锁定。这样，我们就可以收集一些与panic相关的信息了，这对我们定位问题的根本原因有很大的帮助。

二、常见问题

2.1 源码分析

Kernel panic - not syncing: Fatal exception in interrupt
查看了一下 linux的源码文件，找到相关位置

//kernel/panic.c
NORET_TYPE void panic(const char * fmt, ...)
{
static char buf[1024];
va_list args;
bust_spinlocks(1);
va_start(args, fmt);
vsnprintf(buf, sizeof(buf), fmt, args);
va_end(args);
printk(KERN_EMERG "Kernel panic - not syncing: %s\n",buf);
bust_spinlocks(0);

//kernel/exit.c
if (unlikely(in_interrupt()))
panic("Aiee, killing interrupt handler!"); #中断处理
if (unlikely(!tsk->pid))
panic("Attempted to kill the idle task!"); #空任务
if (unlikely(tsk->pid == 1))
panic("Attempted to kill init!"); #初始化

从其他源文件和相关文档看到应该有几种原因：

2.2 硬件问题

使用了 SCSI-device 并且使用了未知命令
WDIOS_TEMPPANIC Kernel panic on temperature trip The SETOPTIONS call can be used to enable and disable the card and to ask the driver to call panic if the system overheats.If one uses a SCSI-device of unsupported type/commands, one immediately runs into a kernel-panic caused by Command Error. To better understand which SCSI-command caused the problem, I extended this specific panic-message slightly.
read/write causes a command error from the subsystem and this causes kernel-panic

2.3 系统过热

如果系统过热会调用panci，系统挂起
WDIOS_TEMPPANIC Kernel panic on temperature trip The SETOPTIONS call can be used to enable and disable the card and to ask the driver to call panic if the system overheats.

2.4 文件系统引起

A variety of panics and hangs with /tmp on a reiserfs filesystem Any other panic, hang, or strange behavior It turns out that there’s a limit of six environment variables on the kernel command line. When that limit is reached or exceeded, argument processing stops, which means that the ‘root=’ argument that UML usually adds is not seen. So, the filesystem has no idea what the root device is, so it panics. The fix is to put less stuff on the command line. Glomming all your setup variables into one is probably the best way to go.

Linux内核命令行有6个环境变量。如果即将达到或者已经超过了的话 root= 参数会没有传进去
启动时会引发panics错误。

//vi grub.conf
#####################
title Red Hat Enterprise Linux AS (2.6.9-67.0.15.ELsmp)
root (hd0,0)
kernel /boot/vmlinuz-2.6.9-67.0.15.ELsmp ro root=LABEL=/
initrd /boot/initrd-2.6.9-67.0.15.ELsmp.img
title Red Hat Enterprise Linux AS-up (2.6.9-67.EL)
root (hd0,0)
kernel /boot/vmlinuz-2.6.9-67.EL ro root=LABEL=/
initrd /boot/initrd-2.6.9-67.EL.img

应该是 其中的 root=LABEL=/ 没有起作用。

2.5 内核更新

网上相关文档多半是因为升级内核引起的，建议使用官方标准版、稳定版
另外还有使用磁盘的lvm 逻辑卷，添加CPU和内存。可在BIOS中禁掉声卡驱动等不必要的设备。
也有报是ext3文件系统的问题。
解决： 手工编译内核，把 ext3相关的模块都编译进去，

2.6 处理panic后的系统自动重启

panic.c源文件有个方法，当panic挂起后，指定超时时间，可以重新启动机器

if (panic_timeout > 0)
{
int i;
/*
* Delay timeout seconds before rebooting the machine.
* We can't use the "normal" timers since we just panicked..
*/
printk(KERN_EMERG "Rebooting in %d seconds..",panic_timeout);
for (i = 0; i < panic_timeout; i++) {
touch_nmi_watchdog();
mdelay(1000);
}

修改方法：

/etc/sysctl.conf文件中加入
kernel.panic = 30 #panic错误中自动重启，等待时间为30秒
kernel.sysrq=1 #激活Magic SysRq！ 否则，键盘鼠标没有响应

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

kernel.panic = 20

来告诉系统从Panic错误中自动重启，等待时间为20秒！这个由管理员自己设定！
另外一个讨厌的事情是系统hung住之后，键盘鼠标没有响应，这个可以通过设置Magic SysRq来试着解决，也是在/etc/sysctl.conf中，

kernel.sysrq=1

来激活Magic SysRq！
这样在挂住的时候至少还有一招可以使，
按住 [ALT]+[SysRq]+[COMMAND], 这里SysRq是Print SCR键，而COMMAND按以下来解释！

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

三、其他相关链接

1、Kdump调试机理总结（一）

2、Kdump配置及使用详细总结（二）

3、crash工具分析vmcore文件常用命令总结（三）

4、Kdump配置及调试内核详解

5、编译linux内核常见报错总结

6、ftrace命令调试内核详细总结