Kernel panic常见原因

kernel 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 !

kernel

错误分析

查看了一下

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

bust_spinlocks(0);

kernel/exit.c

if (unlikely(in_interrupt()))

panic(

中断处理

if (unlikely(!tsk->pid))

panic(

空任务

if (unlikely(tsk->pid == 1))

panic(

初始化

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

1

、硬件问题

使用了

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

、系统过热

如果系统过热会调用

panci

，系统挂起

< br>

#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.

3

、文件系统引起

#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=

参数会没

有传进去

< br>启动时会引发

panics

错误。

vi

#####################

title Red Hat Enterprise Linux AS ()

root (hd0,0)

kernel /boot/ ro root=LABEL=/

initrd /boot/

title Red Hat Enterprise Linux AS-up ()

root (hd0,0)

kernel /boot/ ro root=LABEL=/

initrd /boot/

应该是

其中的

root=LABEL=/

没有起作用。

4

、内核更新

网上相关文档多半是因为升级内核引起的，建议使用官方标准版、稳定版

另外还有使用磁盘的

lvm

逻辑卷， 添加

CPU

和内存。可在

BIOS

中禁掉声卡驱动等不

必要的设备。

也有报是

ext3

文件系统的问题。

解决：

手工编译内核，把

ext3

相关的模块都编译进去，

5

、处理

p anic

后的系统自动重启

panic.c

源文件有个方法，当

pani c

挂起后，指定超时时间，可以重新启动机器

if (panic_timeout > 0)

{

int i;

/*

* Delay timeout seconds before rebooting the machine.

* We can't use the

*/

printk(KERN_EMERG

for (i = 0; i < panic_timeout; i++) {

touch_nmi_watchdog();

mdelay(1000);

}

修改方法：

/etc/

文件中加入

= 30 #panic

错误中自动重启，等待时间为

30

秒

=1 #

激活

Magic SysRq

！

否则，键盘鼠标没有响应

Linux Kernel Panic

之后的招数

Linux

的稳定性勿容置疑，但是有些时候一些

Kerne l

的致命错误还是会发生（有些时候

甚至是因为硬件的原因或驱 动故障），

Kernel Panic

会导致系统

crash

，并且默认的系统会一

直

hung

在那里，直到你去把它重新启动！

不过你可以在

/etc/

文件中加入

= 20

来告诉系统从

Panic

错误中自动重启，等待时间为

20

秒！这个由管理员自己设定！

另外一个讨厌的事情 是系统

hung

住之后，

键盘鼠标没有 响应，

这个可以通过设置

Magic SysRq

来试着解决，也是在

/etc/

中，

=1

来激活

Magic SysRq

！

这样在挂住的时候至少还有一招可以使，

按住

[ALT]+[SysRq]+[COMMAND],

这里

SysRq

是

Print SCR

键，

而

COM MAND

按以下来解释！

b

-

立即重启

e -

< br>发送

SIGTERM

给

init

之外的系统进程

o -

关机

s - sync

同步所有的文件系统

u -

试图重新挂载文件系统

当然，谁也不 希望经常用到这些招数！

:O

，有备无患而已

< br>

Kernel

panic

问题如何调试

Linux kernel panic

是很难定位和排查的重 大故障

,

一旦系统发生了

kernel panic

，相关

的日志信息非常少，而一种常见的排查方法< /p>

—

重现法

–

又很 难实现，因此遇到

kernel panic

的问题，一般比较头疼。

没有一个万能和完美的方法来解决所有的

kernel pan ic

问题，

这篇文章仅仅只是给出一

些 思路，

一来如何解决

kernel panic

的问题，

二来可以尽可能减少发生

kernel panic

的机会。

什么是

kernel panic

< /p>

就像名字所暗示的那样，

它表示

Linu x kernel

走到了一个不知道该怎么走下一步的状况，

一

旦到这个情况，

kernel

就尽可能 把它此时能获取的全部信息都打印出来，

至于能打印出多少

信息 ，那就看是那种情况导致它

panic

了。

有两种主要类型

kernel panic

：

panic(

也就是

Aieee

信息输出

< br>)

panic (

也就是

O ops

信息输出

)

什么能导致

kernel panic

只有加载到内核空间的驱动模块才能直接导致

kernel p anic

，你可以在系统正常的情况下，

使用

< br>lsmod

查看当前系统加载了哪些模块。

除此之外，内建在内核里的组件（比如

memory map< /p>

等）也能导致

panic

。

因为

hard panic

和

soft panic

本质上不同，因此我们分别讨论。

如何排查

hard panic

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

kernel panic:

1.

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

2.

数字键

(Num Lock)

，大写锁定键

(Caps Lock)

，滚动锁定键

(Scroll Lock)

不停闪烁。

3.

如果在终端下，应该可以看到内核

dump

出 来的信息（包括一段

”Aieee”

信息或

者

”Oops”

信息）

4.

和

Windows

蓝屏相似

原因：

对于

hard panic

而言，最大 的可能性是驱动模块的中断处理

(interrupt handler)

导致的，一

般是因为驱动模块在中断处理程序中访问一个空指针

(null pointre)

。一旦发生这种情况，驱

动模块就无法处理新的中断请求，最终导致系统崩溃。

信息收集

根据

panic

的状态不同，内核将记录所有在系统锁定之前的信息。因为

kenrel panic

是一种

很严重的错误，

不能确定系统能记录多少信息，

下面是一些需要收集的关键信息，< /p>

他们非常

重要，因此尽可能收集全，当然如果系统启动的时候就< /p>

kernel panic

，那就无法只知道能收

集到多少有用的信息了。

1.

/var/log/messages:

幸运的时候，整个

kernel panic

栈跟踪信息都能记录在这里。

2.

应用程序

/

库

日志

:

可能可以从这些日志信息里能 看到发生

panic

之前发生了什么。

3.

其他发生

panic