如何快速对系统重启问题进行归类

原文：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的分配流程。

顶

踩