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

当手机发生系统重启,即导致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解开来会包含如下的 档案:

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 addressXXXXXXXX

如上的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 arm64platformPC is at aee_wdt_atf_info+0x4c8/0x6dc

LR is at aee_wdt_atf_info+0x4c0/0x6dc

for arm32platform

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