Linux内核：进程管理|——崩溃日志

1.Linux Kernel Panic的产生的原因

panic是英文中是惊慌的意思，Linux Kernel panic正如其名，linux kernel不知道如何走了，它会尽可能把它此时能获取的全部信息都打印出来。

有两种主要类型kernel panic，后面会对这两类panic做详细说明：

1.hard panic(也就是Aieee信息输出)
2.soft panic (也就是Oops信息输出)

2.常见Linux Kernel Panic报错内容：

(1) Kernel panic-not syncing fatal exception in interrupt
(2) kernel panic – not syncing: Attempted to kill the idle task!
(3) kernel panic – not syncing: killing interrupt handler!
(4) Kernel Panic – not syncing：Attempted to kill init !

3. 什么会导致Linux Kernel Panic?

只有加载到内核空间的驱动模块才能直接导致kernel panic，你可以在系统正常的情况下，使用lsmod查看当前系统加载了哪些模块。

除此之外，内建在内核里的组件（比如memory map等）也能导致panic。

因为hard panic和soft panic本质上不同，因此我们分别讨论。

4. hard panic

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

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

4.1 原因

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

本人就曾遇到过这样一个例子：在多核系统中，包括AP应用处理器、mcu微控制器和modem处理器等系统中，mcu控制器用于系统的低功耗控制，mcu微控制器由于某种原因超时向AP应用处理器发送一个超时中断，AP接受中断后调用中断处理函数读取mcu的状态寄存器，发现是mcu的超时中断，就在中断处理程序中主动引用一个空指针，迫使AP处理器打印堆栈信息然后重启linux系统。这就是一个典型的hard panic，这里不对mcu超时原因做深入的分析，只是用来说明hard panic产生的机理。

5. soft panic

5.1 症状：

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

5.2 原因

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

什么是fatal exception?

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

软件应用程序通过几个不同的代码层与操作系统及其他应用程序相联系。当异常（exception）在某个代码层发生时，为了查找所有异常处理的代码，各个代码层都会将这个异常发送给下一层，这样就能够处理这种异常。如果在所有层都没有这种异常