所有資訊僅對arm晶元有效。
32位：
crash -m phys_base=0x80000000 vmlinux sysdump.core
0x80000000是指ddr起始地實體地址 vmlinux是帶符號資訊的vmlinux檔案 sysdump.core是dump機制拉出來的核心mem映像 。
64位：
crash -m phy_offset=0x80000000 vmlinux sysdump.core
注意vmlinux和sysdump.core必須一致，否則一般是無法解析出來的。
解析出來後就進去crash>這樣子的互動介面。
通常我們會在**裡用一些全域性的變數記錄一些重要資訊（中斷，暫存器訪問，bus-monitor等等）如spreadtrum的乙個記錄暫存器訪問的全域性變數是是sprd_debug_last_access_regs
crash>sprd_debug_last_access_regs
會顯示這個全域性變數的位址 比如0x80000ff0
crash>struct sprd_debug_last_access_regs 0x80000ff0
就會詳細的列印出這個位址對應的結構體的內容
從而檢視是否是暫存器訪問不成功導致系統掛死。
要看乙個執行緒的核心棧，知道其執行緒號時，比如214
執行以下命令：bt -r 214
就會列印出其核心棧，需要注意的是高版本的核心棧一般是8k，且頭部有thread_info資訊，不要將thread_info部分的內容當成是核心的棧呼叫資訊，從而錯誤判斷核心函式呼叫鏈，debug問題方向發生偏差。
需要注意的是核心棧往往很難追查，一般需要對照會變**去重現呼叫鏈。
但是往往核心的彙編**函式的第乙個條指令都是把lr和pc和其他需要入棧的暫存器入棧：
kernel_function:
push
類似這樣子，而我們知道arm的pc值是當前執行指令位址+8，所以這個時候入棧的pc值是函式起始位址+12，也就是kernel_function，從而你看到核心棧裡有倆個函式+偏移量在一起，那一般就是被儲存下來的lr和pc，根據這樣子的規律就可以層層剝開來，找到核心呼叫鏈。要注意的事中斷會使用核心棧，所以有的時候你會看到核心呼叫棧被打斷，出現中斷裡的函式執行，這部分要被去掉，才能正確的還原核心呼叫鏈。當然，從被打斷的部分也可以看看是否中斷裡出了問題。
要檢視當前正在各個核上執行的執行緒：
ps |grep ">"
ps |grep "un"
ps |grep "in"
Linux核心Crash分析
每乙個程序的生命週期內，其生命週期的範圍為幾毫秒到幾個月。一般都是和核心有互動，例如使用者空間程式使用系統呼叫進入核心空間。這時使用的不再是使用者空間的棧空間，使用對應的核心棧空間。對每乙個程序來說，linux核心都會把兩個不同的資料結構緊湊的存放在乙個單獨為程序分配的儲存空間中 乙個是核心態的程序...
crash除錯核心模組
wifi 模組出現panic時，怎麼根據fulldump去分析wifi問題，以及怎麼除錯wlan的ko檔案？這裡介紹linux下的crash工具來分析fulldump,當然也可以用trace32,gdb等其他工具.1.安裝crash工具 編譯和安裝 make target arm64 make in...
Linux核心Crash分析 重要
linux核心crash分析 每乙個程序的生命週期內，其生命週期的範圍為幾毫秒到幾個月。一般都是和核心有互動，例如使用者空間程式使用系統呼叫進入核心空間。這時使用的不再是使用者空間的棧空間，使用對應的核心棧空間。對每乙個程序來說，linux核心都會把兩個不同的資料結構緊湊的存放在乙個單獨為程序分配的...