本文信息

CSDN	GitHub
Linux Kernel PANIC(一)–概述(Hard Panic/Aieee和Soft Panic/Oops)	`LDD-LinuxDeviceDrivers/study/debug/modules/panic/01-kernel_panic`

同類博文信息

CSDN	GitHub
Linux Kernel PANIC(一)–概述(Hard Panic/Aieee和Soft Panic/Oops)	`LDD-LinuxDeviceDrivers/study/debug/modules/panic/01-kernel_panic`
Linux Kernel PANIC(二)–Hard Panic/Aieee實例分析	`LDD-LinuxDeviceDrivers/study/debug/modules/panic/02-hard_panic`
Linux Kernel PANIC(三)–Soft Panic/Oops調試及實例分析	`LDD-LinuxDeviceDrivers/study/debug/modules/panic/03-soft_panic`

本作品採用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議進行許可, 轉載請註明出處

1 Kernel PANIC/OOPS

wiki:A kernel panic is an action taken by an operating system upon detecting an internal fatal error from which it cannot safely recover. The term is largely specific to Unix and Unix-like systems; for Microsoft Windowsoperating systems the equivalent term is “Bug check” (or, colloquially, “Blue Screen of Death“).
The kernel routines that handle panics (in AT&T-derived and BSD Unix source code, a routine known as panic()) are generally designed to output an error message to the console, dump an image of kernel memory to disk for post-mortemdebugging and then either wait for the system to be manually rebooted, or initiate an automatic reboot. The information provided is of highly technical nature and aims to assist a system administrator or software developer in diagnosing the problem.
Attempts by the operating system to read an invalid or non-permitted memory address are a common source of kernel panics. A panic may also occur as a result of a hardware failure or a bug in the operating system. In many cases, the operating system could continue operation after memory violations have occurred. However, the system is in an unstable state and rather than risking security breaches and data corruption, the operating system stops to prevent further damage and facilitate diagnosis of the error.
The kernel panic was introduced in an early version of Unix and demonstrated a major difference between the design philosophies of Unix and its predecessor Multics. Multics developer Tom van Vleck recalls a discussion of this change with Unix developer Dennis Ritchie:
I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, “We left all that stuff out. If there’s an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, ‘Hey, reboot it.’”[1]
The original panic() function was essentially unchanged from Fifth Edition UNIX to the VAX-based UNIX 32V and output only an error message with no other information, then dropped the system into an endless idle loop. As the Unixcodebase was enhanced, the panic() function was also enhanced to dump various forms of debugging information to the console.

1.1 什麼是 `Kernel PANIC`

panic 是英文中是驚慌的意思, Linux Kernel panic 正如其名, Linux Kernel 不知道如何走了, 它會儘可能把它此時能獲取的全部信息都打印出來, 爲開發人員調試提供幫助.

有兩種主要類型 Kernel panic

Hard Panic(也就是Aieee信息輸出)
Soft Panic(也就是Oops信息輸出)

1.2 什麼會導致Linux Kernel Panic

只有加載到內核空間的驅動模塊才能直接導致 kernel panic, 你可以在系統正常的情況下, 使用 lsmod 查看當前系統加載了哪些模塊. 除此之外, 內建在內核裏的組件(比如 memory map等)也能導致panic.

常見Linux 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 panic :

機器徹底被鎖定，不能使用
數字鍵(Num Lock)，大寫鎖定鍵(Caps Lock)，滾動鎖定鍵(Scroll Lock)不停閃爍。
如果在終端下，應該可以看到內核dump出來的信息（包括一段”Aieee”信息或者”Oops”信息）
和Windows藍屏相似

因爲 hard panic 和 soft panic 本質上不同，因此我們分別討論.

2 hard panic

對於 hard panic 而言, 最大的可能性是驅動模塊的中斷處理(interrupt handler)導致的, 一般是因爲驅動模塊在中斷處理程序中訪問一個空指針(null pointer).

一旦發生這種情況，驅動模塊就無法處理新的中斷請求，最終導致系統崩潰.

2.1 原因

對於 hard panic 而言，最大的可能性是驅動模塊的中斷處理(interrupt handler)導致的，一般是因爲驅動模塊在中斷處理程序中訪問一個空指針(null pointre).

一旦發生這種情況, 驅動模塊就無法處理新的中斷請求, 最終導致系統崩潰.

2.2 信息收集

根據 panic 的狀態不同, 內核將記錄所有在系統鎖定之前的信息. 因爲 kenrel panic 是一種很嚴重的錯誤, 不能確定系統能記錄多少信息, 下面是一些需要收集的關鍵信息, 他們非常重要，因此儘可能收集全，當然如果系統啓動的時候就kernel panic，那就無法只知道能收集到多少有用的信息了。

/var/log/messages, 幸運的時候, 整個 kernel panic 棧跟蹤信息都能記錄在這裏. 要確認是否有一個足夠的棧跟蹤信息，你只要查找包含”EIP”的一行, 它顯示了是什麼函數和模塊調用時導致panic.
應用程序/庫日誌: 可能可以從這些日誌信息裏能看到發生 panic 之前發生了什麼。
其他發生 panic 之前的信息, 或者知道如何重現panic那一刻的狀態
終端屏幕 dump信息, 一般 OS被鎖定後, 複製, 粘貼肯定是沒戲了, 因此這類信息, 你可以需要藉助數碼相機或者原始的紙筆工具了.

如果 kernel dump 信息既沒有在 /var/log/message 裏, 也沒有在屏幕上, 那麼嘗試下面的方法來獲取(當然是在還沒有死機的情況下).

如果在圖形界面，切換到終端界面，dump信息是不會出現在圖形界面的，甚至都不會在圖形模式下的虛擬終端裏.
確保屏幕不黑屏，可以使用下面的幾個方法：
```
setterm -blank 0
setterm -powerdown 0
setvesablank off
```
從終端，拷貝屏幕信息

2.3 排查方法

棧跟蹤信息(stack trace)是排查 kernel panic 最重要的信息, 該信息如果在/var/log/messages日誌裏當然最好，因爲可以看到全部的信息，如果僅僅只是在屏幕上，那麼最上面的信息可能因爲滾屏消失了，只剩下棧跟蹤信息的一部分。如果你有一個完整棧跟蹤信息的話，那麼就可能根據這些充分的信息來定位panic的根本原因。要確認是否有一個足夠的棧跟蹤信息，你只要查找包含”EIP”的一行，它顯示了是什麼函數和模塊調用時導致panic

使用內核調試工具(kenrel debugger ,aka KDB)
如果跟蹤信息只有一部分且不足以用來定位問題的根本原因時, kernel debugger(KDB)就需要請出來了。

KDB編譯到內核裏，panic發生時，他將內核引導到一個shell環境而不是鎖定。這樣，我們就可以收集一些與panic相關的信息了，這對我們定位問題的根本原因有很大的幫助。

3 soft panic

症狀沒有 hard panic嚴重
通常導致段錯誤(segmentation fault)
以看到一個 oops 信息, /var/log/messages裏可以搜索到’Oops’.
機器稍微還能用(但是收集信息後，應該會重啓系統).

3.1 原因

凡是非中斷處理引發的模塊崩潰都將導致 soft panic

在這種情況下, 驅動本身會崩潰, 但是還不至於讓系統出現致命性失敗, 因爲它沒有鎖定中斷處理例程. 導致 hard panic的原因同樣對soft panic也有用(比如在運行時訪問一個空指針).

3.2 信息收集

當 soft panic發生時, 內核將產生一個包含內核符號(kernel symbols)信息的 dump數據, 這個將記錄在/var/log/messages裏.

3.3 排查方法

爲了開始排查故障, 可以使用 ksymoops 工具來把內核符號信息轉成有意義的數據.

爲了生成ksymoops文件,需要

從 /var/log/messages 裏找到的堆棧跟蹤文本信息保存爲一個新文件。確保刪除了時間戳(timestamp)，否則 ksymoops 會失敗.
運行 ksymoops 程序（如果沒有，請安裝）
詳細的ksymoops執行用法，可以參考ksymoops(8)手冊。

Oops 可以看成是內核級的 Segmentation Fault.

應用程序如果進行了非法內存訪問或執行了非法指令, 會得到 Segfault 信號, 一般的行爲是 coredump, 應用程序也可以自己截獲Segfault 信號，自行處理
如果內核自己犯了這樣的錯誤, 則會打出 Oops 信息.

處理器使用的所有地址幾乎都是通過一個複雜的頁表結構對物理地址映射而得到的虛擬地址(除了內存管理子系統自己所使用的物理地址)。當一個非法的指針被廢棄時，內存分頁機制將不能爲指針映射一個物理地址，處理器就會向操作系統發出一個頁故障信號。如果地址不合法，那麼內核將不能在該地址“布頁”；這時如果處理器處於超級用戶模式，內核就會生成一條oops消息。