（1）什麼是Kernel Panic?

        panic是英文中是驚慌的意思，Linux Kernel panic正如其名，linux kernel不知道如何走了，它會盡可能把它此時能獲取的全部資訊都打印出來。有兩種主要型別kernel panic：
1.hard panic(也就是Aieee資訊輸出)；2.soft panic (也就是Oops資訊輸出)

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

（3）hard panic

        對於hard panic而言，最大的可能性是驅動模組的中斷處理(interrupt handler)導致的，一般是因為驅動模組在中斷處理程式中訪問一個空指標(null pointer)。一旦發生這種情況，驅動模組就無法處理新的中斷請求，最終導致系統崩潰。

        根據panic的狀態不同，核心將記錄所有在系統鎖定之前的資訊。因為kenrel panic是一種很嚴重的錯誤，不能確定系統能記錄多少資訊，下面是一些需要收集的關鍵資訊：

a，/var/log/messages: 幸運的時候，整個kernel panic棧跟蹤資訊都能記錄在這裡。要確認是否有一個足夠的棧跟蹤資訊，你只要查詢包含”EIP”的一行，它顯示了是什麼函式和模組呼叫時導致panic。
b，終端螢幕dump資訊，一般OS被鎖定後，複製，貼上肯定是沒戲了，因此這類資訊，你可以需要藉助拍照了。

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

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

（5）fatal exception

        “致命異常（fatal exception）表示一種例外情況，這種情況要求導致其發生的程式關閉。通常，異常（exception）可能是任何意想不到的情況（它不僅僅包括程式錯誤）。致命異常簡單地說就是異常不能被妥善處理以至於程式不能繼續執行。
        軟體應用程式通過幾個不同的程式碼層與作業系統及其他應用程式相聯絡。當異常（exception）在某個程式碼層發生時，為了查詢所有異常處理的程式碼，各個程式碼層都會將這個異常傳送給下一層，這樣就能夠處理這種異常。如果在所有層都沒有這種異常處理的程式碼，致命異常（fatal exception）錯誤資訊就會由作業系統顯示出來。這個資訊可能還包含一些關於該致命異常錯誤發生位置的祕密資訊（比如在程式儲存範圍中的十六進位制的位置）。這些額外的資訊對使用者而言沒有什麼價值，但是可以幫助技術支援人員或開發人員除錯程式。

        當致命異常（fatal exception）發生時，作業系統沒有其他的求助方式只能關閉應用程式，並且在有些情況下是關閉作業系統本身。

（6）安裝linux系統遇到安裝完成之後，無法啟動系統出現Kernel panic-not syncing fatal exception。很多情況是由於板載音效卡、網絡卡、或是cpu 超執行緒功能（Hyper-Threading ）引起的。這類問題的解決辦法就是先檢視錯誤程式碼中的資訊（諸如cut here，Modules linked in，PC is at，LR is at，Unable to handle kernelNULL pointer ），找到錯誤所指向的硬體，將其禁用。系統啟動後，安裝好相應的驅動，再啟用該硬體即可（針對linux桌面系統）。

===================addr2line工具使用============

        使用addr2line工具，有助於我們對核心崩潰現場進行分析，找到崩潰的檔案和程式碼函式。

（1）先實驗函式名對應的地址，再驗證通過地址解析出函式名和行數

參見http://blog.csdn.net/whz_zb/article/details/7604760

（2）通過核心崩潰PC找到出錯函式例項，比如如下崩潰欄位：可以看到程式計數器PC是0xc03214cc。

(171012_20:25:54.609)PC is at __spi_sync+0x34/0x98
(171012_20:25:54.609)LR is at __spi_sync+0x20/0x98
(171012_20:25:54.609)pc : [<c032154c>]    lr : [<c0321538>]    psr: 600d0113
(171012_20:25:54.609)sp : ce6a3e08  ip : ce6a3e18  fp : 00000005
(171012_20:25:54.609)r10: 0000b4a8  r9 : dfcc7030  r8 : 00000030
(171012_20:25:54.609)r7 : 00000000  r6 : 00000000  r5 : 00000036  r4 : ce6a3e80
(171012_20:25:54.668)r3 : c0321404  r2 : ffffffd0  r1 : 00000000  r0 : ce6a3e08
(171012_20:25:54.669)Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
(171012_20:25:54.669)Control: 10c5387d  Table: 0d27c06a  DAC: 00000055
(171012_20:25:54.669)PC: 0xc03214cc:

找到對應核心的vmlinux二進位制符號庫（大概125M），然後執行如下命令，其中-e 選項來指定可執行映像。-f 選項，可以告訴工具輸出函式名。

[email protected]:~/workspace/temp$ addr2line 0xc03214cc -e vmlinux -f
spi_async_locked

/home/sw01/workspace/fm1388/atc8317M/kernel/kernel-3.18/drivers/spi/spi.c:2064

（3）根據PC可以找到另一種處理方法

PC is at mali_sync_flag_signal+0x10/0x24 [mali]
LR is at mali_timeline_sync_fence_activate+0x18/0x34 [mali]
pc : [<bf6e3798>]    lr : [<bf6e25d0>]    psr: 600f0193
sp : c0c01e00  ip : 800f0193  fp : cdc25f00

r10: 00000000  r9 : 00000000  r8 : ca9ce480

PC最後指向mali_sync_flag_signal函式的0x10偏移；根據Mali.ko反彙編得到如下結果：

結合彙編程式碼可以看到是上圖高亮的一句話，在將r1的內容寫入r0+8的記憶體時發生定址錯誤導致crash。

===============Kernel cut here====================================

Linux有時會提示cut here片段，類似核心崩潰但其實不是的棧LOG。比如：

[W]------------[ cut here ]------------
[W]WARNING: CPU: 1 PID: 1 at /home/sw01/workspace/fm1388/atc8317M/kernel/kernel-3.18/drivers/base/core.c:551 device_create_file+0x68/0x88()
Attribute fm1388_addr: read permission without 'show'
Modules linked in: i2c_fm1388(+) wlan_gen3 mtk_wmt_wifi mtk_stp_gps mtk_stp_bt mtk_stp_sdio mtk_stp_uart mtk_stp_wmt mtk_hif_sdio e52241_charger input drvcli(P) dvpagent i2c_dev gt9xx gps_6630 sonix_uvcvideo mali ump gdec pdec mtz_drv jdec imgcommon(P) avin videobuf_dma_contig videobuf2_dma_contig videobf2_vmalloc videobuf2_memops videobuf2_core videobuf_core mhldrv vdec drvdmx drvmmisc tvd wch adec drvstc backcar dualarmdrv fb1 atcfb vcp gfx irtdma imgresz [last unloaded: mtk_wmt_detect]
CPU: 1 PID: 1 Comm: init Tainted: P               3.18.0+ #23

[<c0015eb0>] (unwind_backtrace) from [<c0012414>] (show_stack+0x10/0x14)
[<c0012414>] (show_stack) from [<c067cf14>] (dump_stack+0x7c/0xd0)
[<c067cf14>] (dump_stack) from [<c0029370>] (warn_slowpath_common+0x64/0x84)
[<c0029370>] (warn_slowpath_common) from [<c0029410>] (warn_slowpath_fmt+0x2c/0x3c)

        從中可以明顯看出提示點“Attribute fm1388_addr: read permission without 'show'”，解決完這個提示即可恢復，不再有這種提示。

===============Tombstone的分析====================================

        當一個動態庫（native 程式）開始執行時，系統會註冊一些連線到 debuggerd 的 signal handlers，當系統 crash 的時候，會儲存一個 tombstone 檔案到/data/tombstones目錄下（Logcat中也會有相應的資訊），檔案的確就像墓碑一樣記錄了死亡了的程序的基本資訊（例如程序的程序號，執行緒號），死亡的地址（在哪個地址上發生了 Crash），死亡時的現場是什麼樣的（記錄了一系列的堆疊呼叫資訊）等等。

        Tombstone的組成以及怎麼分析tombstone檔案，另外還有些分析工具（1）addr2line，上文已講，（2）ndk-stack。參見網文：https://www.cnblogs.com/CoderTian/p/5980426.html。

參考原文：http://blog.51osos.com/linux/linux-kernel-panic/