如何快速對系統重新開機問題進行歸類

原文：http://xiaobai.m.blog.chinaunix.net/uid-29728680-id-5567130.html

[DESCRIPTION]    當手機發生系統重新開機，即導緻kernel重新開機的異常時，會在手機中的/data/aee_exp目錄下儲存異常重新開機的db。工程師可以通過GAT的bug report功能，或者直接通過adb pull，把對應的db從手機中抓回來。進一步，對于異常重新開機的類型，需要通過GAT工具解開db檔案（解開方式參考MTK-online上的文檔GAT_User_Guide(Customer).docx之5.1的部分），對裡面的SYS_KERNEL_LOG/SYS_LAST_LOG/SYS_REBOOT_REASON 内容進行解析，才能知道具體的重新開機的類型。  一般來說，導緻kernel重新開機的異常重新開機，包括Kernel Panic, Watchdog Timeout, Hardware Reboot這三種類型。一個完整的Kernel Panic，其db解開來會包含如下的 檔案：  

    [SOLUTION]    1. Kernel Panic     即linux kernel發生了無法修複的錯誤，進而導緻panic。通過檢視SYS_KERNEL_LOG的内容，kernel Panic進一步可以分為如下幾類： a. 普通的data abort。從SYS_KERNEL_LOG中，可以檢索到如下的info:   Unable to handle kernel NULL pointer dereference at virtual address XXXXXXXX   如上的XXXXXXXX代表某個非法位址。這種類型是最多的。   b. oom 主動觸發的panic。從SYS_KERNEL_LOG中，可以檢索到如下的info:   Kernel panic - not syncing: Out of memory and no killable processes...   此種類型的panic一般是某個process或者APK耗盡了memory資源，進而kernel主動觸發的panic重新開機。對于這種類型的重新開機，強烈建議工程師把如上的info填寫到eService 的标題中，這樣MTK可以對eService進行一次到位的配置設定。   c. undefined instruction，未定義指令異常。從SYS_KERNEL_LOG中，可以檢索到如下的info:   Internal error: Oops - undefined instruction   此類異常較為少見，可能是CPU/DRAM 不穩定或者受幹擾導緻的問題。   d. bad mode異常，即PC處于一個無效的virtual address。從SYS_KERNEL_LOG中，可以檢索到如下的info:   Bad mode in Synchronous Abort handler detected ... [14820.652408]-(1)[682:VSyncThread_0][] bad_mode+0x78/0xb0   此類異常較為少見，可能的原因是stack錯亂，或者未注冊回調函數引起。     2. watchdog 逾時   a. 底層看門狗逾時。從SYS_KERNEL_LOG中，可以檢索到如下的info:   for arm64 platform PC is at aee_wdt_atf_info+0x4c8/0x6dc LR is at aee_wdt_atf_info+0x4c0/0x6dc   for arm32 platform PC is at aee_wdt_irq_info+0x104/0x12c LR is at aee_wdt_irq_info+0x104/0x12c   此類異常較為常見，多見于底層頻繁irq/bus卡死，導緻kicker無法被schedule，進而引起watch dog觸發中斷，引導系統進入FIQ處理流程，最終call到BUG觸發重新開機。   b.上層hang_detect 觸發看門狗逾時。從SYS_KERNEL_LOG中，可以檢索到如下的info:   [ 2131.086562] (0)[77:hang_detect][Hang_Detect] we should triger HWT ... ...   [ 2180.467416]-(0)[77:hang_detect]PC is at aee_wdt_irq_info+0x154/0x170

[ 2180.467426]-(0)[77:hang_detect]LR is at aee_wdt_irq_info+0x154/0x170 ...   此異常類型較為常見，多見于GPU/SD卡/eMMC 無法滿足surfacelinger/system_server的通訊需求，進而導緻上層卡死，進而主動觸發看門狗逾時重新開機。對于這種類型的重新開機，強烈建議工程師把如上的Hang_Detect關鍵字填寫到eService 的标題中，這樣MTK可以對eService進行一次到位的配置設定。   3. Hardware Reboot   hardware reboot是watch dog直接發出reset信号，導緻整個系統重新開機；在重新開機之前，并沒有觸發任何異常處理流程。一般情況下，hardware reboot對應的db不會有SYS_KERNEL_LOG 可以排查，隻能從SYS_LAST_KMSG獲知異常之前kernel的動作，以及從SYS_REBOOT_REASON 獲知異常時的CPU寄存器值和其它參數。 從ZZ_INTERNAL 檔案，可以知道發生了hardware reboot Hardware Reboot,0,0,99,/data/core/,0,,HW_REBOOT,Fri Jul  3 14:31:53 CST 2015,1       就上面所羅列的諸多異常重新開機，工程師務必把如上黃底部分的log片段拷貝到eService的Description欄位，并把紅色的關鍵字填寫到eService的标題中，這樣，可以大大加快eService的配置設定流程。

頂

踩