[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解开来会包含如下的 档案：
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][<ffffffc000088f90>] 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的分配流程。
