linux kernel panic解決思路

Linux kernel panic是很難定位和排查的重大故障,一旦系統發生了kernel panic，相關的日誌資訊非常少，而一種常見的排查方法—重現法–又很難實現，因此遇到kernel panic的問題，一般比較頭疼。
沒有一個萬能和完美的方法來解決所有的kernel panic問題，這篇文章僅僅只是給出一些思路，一來如何解決kernel panic的問題，二來可以儘可能減少發生kernel panic的機會。

什麼是kernel panic

就像名字所暗示的那樣，它表示Linux kernel走到了一個不知道該怎麼走下一步的狀況，一旦到這個情況，kernel就儘可能把它此時能擷取的全部資訊都列印出來，至於能列印出多少資訊，那就看是那種情況導致它panic了。

有兩種主要類型kernel panic：

1.hard panic(也就是Aieee資訊輸出)
2.soft panic (也就是Oops資訊輸出)

什麼能導致kernel panic

只有載入到核心空間的驅動模組才能直接導致kernel panic，你可以在系統正常的情況下，使用lsmod查看當前系統載入了哪些模組。
除此之外，內建在核心裡的組件（比如memory map等）也能導致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 指標(null pointre)。一旦發生這種情況，驅動模組就無法處理新的插斷要求，最終導致系統崩潰。

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

1. /var/log/messages: 幸運的時候，整個kernel panic棧跟蹤資訊都能記錄在這裡。
2. 應用程式/庫 日誌: 可能可以從這些日誌資訊裡能看到發生panic之前發生了什麼。
3. 其他發生panic之前的資訊，或者知道如何重現panic那一刻的狀態
4. 終端螢幕dump資訊，一般OS被鎖定後，複製，粘貼肯定是沒戲了，因此這類資訊，你可以需要藉助數位相機或者原始的紙筆工具了。

如果kernel dump資訊既沒有在/var/log/message裡，也沒有在螢幕上，那麼嘗試下面的方法來擷取（當然是在還沒有死機的情況下）：

1. 如果在圖形介面，切換到終端介面，dump資訊是不會出現在圖形介面的，甚至都不會在圖形模式下的虛擬終端裡。
2. 確保螢幕不黑屏，可以使用下面的幾個方法：
   • setterm -blank 0
   • setterm -powerdown 0
   • setvesablank off
3. 從終端，拷貝螢幕資訊（方法見上）

完整棧跟蹤資訊的排查方法

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

EIP is at _dlgn_setevmask [streams-dlgnDriver] 0xe

hard panic的一個完整跟蹤資訊例子：

Unable to handle kernel NULL pointer dereference at virtual address 0000000c

printing eip:

f89e568a

*pde = 32859001

*pte = 00000000

Oops: 0000

Kernel 2.4.9-31enterprise

CPU: 1

EIP: 0010:[<f89e568a>] Tainted: PF

EFLAGS: 00010096

EIP is at _dlgn_setevmask [streams-dlgnDriver] 0xe

eax: 00000000 ebx: f65f5410 ecx: f5e16710 edx: f65f5410

esi: 00001ea0 edi: f5e23c30 ebp: f65f5410 esp: f1cf7e78

ds: 0018 es: 0018 ss: 0018

Process pwcallmgr (pid: 10334, stackpage=f1cf7000)

Stack: 00000000 c01067fa 00000086 f1cf7ec0 00001ea0 f5e23c30 f65f5410 f89e53ec

f89fcd60 f5e16710 f65f5410 f65f5410 f8a54420 f1cf7ec0 f8a4d73a 0000139e

f5e16710 f89fcd60 00000086 f5e16710 f5e16754 f65f5410 0000034a f894e648

Call Trace: [setup_sigcontext+218/288] setup_sigcontext [kernel] 0xda

Call Trace: [<c01067fa>] setup_sigcontext [kernel] 0xda

[<f89e53ec>] dlgnwput [streams-dlgnDriver] 0xe8

[<f89fcd60>] Sm_Handle [streams-dlgnDriver] 0×1ea0

[<f8a54420>] intdrv_lock [streams-dlgnDriver] 0×0

[<f8a4d73a>] Gn_Maxpm [streams-dlgnDriver] 0×8ba

[<f89fcd60>] Sm_Handle [streams-dlgnDriver] 0×1ea0

[<f894e648>] lis_safe_putnext [streams] 0×168

[<f8a7b098>] __insmod_streams-dvbmDriver_S.bss_L117376 [streams-dvbmDriver] 0xab8

[<f8a78821>] dvbmwput [streams-dvbmDriver] 0×6f5

[<f8a79f98>] dvwinit [streams-dvbmDriver] 0×2c0

[<f894e648>] lis_safe_putnext [streams] 0×168

[<f893e6d8>] lis_strputpmsg [streams] 0×54c

[<f895482e>] __insmod_streams_S.rodata_L35552 [streams] 0×182e

[<f8951227>] sys_putpmsg [streams] 0×6f

[system_call+51/56] system_call [kernel] 0×33

[<c010719b>] system_call [kernel] 0×33

Nov 28 12:17:58 talus kernel:

Nov 28 12:17:58 talus kernel:

Code: 8b 70 0c 8b 06 83 f8 20 8b 54 24 20 8b 6c 24 24 76 1c 89 5c

完整棧資訊無效的排查方法

如果只有部分跟蹤資訊，要快速定位問題的根本原因就變得很難，因為沒有明顯的資訊來告訴我們是哪個模組或者函數的調用導致了核心panic，你可能只能看到kernel最後的一些指令。這種情況下，要儘可能多的收集資訊，包括程式日誌，庫的跟蹤資訊，故障重現的步驟等。

Hard panic 部分跟蹤資訊例子（沒有EIP資訊）：
[<c01e42e7>] ip_rcv [kernel] 0×357
[<f8a179d5>] sramintr [streams_dlgnDriver] 0×32d
[<f89a3999>] lis_spin_lock_irqsave_fcn [streams] 0×7d
[<f8a82fdc>] inthw_lock [streams_dlgnDriver] 0×1c
[<f8a7bad8>] pwswtbl [streams_dlgnDriver] 0×0
[<f8a15442>] dlgnintr [streams_dlgnDriver] 0×4b
[<f8a7c30a>] Gn_Maxpm [streams_dlgnDriver] 0×7ae
[<c0123bc1>] __run_timers [kernel] 0xd1
[<c0108a6e>] handle_IRQ_event [kernel] 0×5e
[<c0108c74>] do_IRQ [kernel] 0xa4
[<c0105410>] default_idle [kernel] 0×0
[<c0105410>] default_idle [kernel] 0×0
[<c022fab0>] call_do_IRQ [kernel] 0×5
[<c0105410>] default_idle [kernel] 0×0
[<c0105410>] default_idle [kernel] 0×0
[<c010543d>] default_idle [kernel] 0×2d
[<c01054c2>] cpu_idle [kernel] 0×2d
[<c011bb86>] __call_console_drivers [kernel] 0×4b
[<c011bcfb>] call_console_drivers [kernel] 0xeb
Code: 8b 50 0c 85 d2 74 31 f6 42 0a 02 74 04 89 44 24 08 31 f6 0f
<0> Kernel panic: Aiee, killing interrupt handler!
In interrupt handler – not syncing

使用核心調試工具(kenrel debugger ,aka KDB)

如果跟蹤資訊只有一部分且不足以用來定位問題的根本原因時，kernel debugger(KDB)就需要請出來了。
KDB編譯到核心裡，panic發生時，他將核心引導到一個shell環境而不是鎖定。這樣，我們就可以收集一些與panic相關的資訊了，這對我們定位問題的根本原因有很大的協助。

使用KDB需要注意，核心必須是基本核心版本，比如是2.4.18，而不是2.4.18-5這樣子的，因為KDB僅對基本核心有效。

如何排查soft panic

癥狀：

1. 沒有hard panic嚴重
2. 通常導致段錯誤(segmentation fault)
3. 可以看到一個oops資訊，/var/log/messages裡可以搜尋到’Oops’
4. 機器稍微還能用（但是收集資訊後，應該重啟系統）

原因：

凡是非中斷處理引發的模組崩潰都將導致soft panic。在這種情況下，驅動本身會崩潰，但是還不至於讓系統出現致命性失敗，因為它沒有鎖定中斷處理常式。導致hard panic的原因同樣對soft panic也有用（比如在運行時訪問一個null 指標)

資訊收集：
當soft panic發生時，核心將產生一個包含核心符號(kernel symbols)資訊的dump資料，這個將記錄在/var/log/messages裡。為了開始排查故障，可以使用ksymoops工具來把核心符號資訊轉成有意義的資料。

為了產生ksymoops檔案,需要：

• 從/var/log/messages裡找到的堆疊追蹤文本資訊儲存為一個新檔案。確保刪除了時間戳記(timestamp)，否則ksymoops會失敗。
• 運行ksymoops程式（如果沒有，請安裝）
• 詳細的ksymoops執行用法，可以參考ksymoops(8)手冊。

下面是一個soft panic的oopsg跟蹤例子：

Code: 8b 70 0c 50 e8 69 f9 f8 ff 83 c4 10 83 f8 08 74 35 66 c7 47
EIP; f89ba71e <[streams-dlgnDriver]_dlgn_setidlestate+1e/8c>
Trace; f8951bd6 <[streams]lis_wakeup_close+86/110>
Trace; f8a2705c <[streams-dlgnDriver]__module_parm_r4_feature+280/1453>
Trace; f8a27040 <[streams-dlgnDriver]__module_parm_r4_feature+264/1453>
Trace; f89b9198 <[streams-dlgnDriver]dlgnwput+e8/204>