Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1372256
  • 博文数量: 478
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 4833
  • 用 户 组: 普通用户
  • 注册时间: 2014-06-28 11:12
文章分类

全部博文(478)

文章存档

2019年(1)

2018年(27)

2017年(21)

2016年(171)

2015年(258)

我的朋友

分类: Android平台

2015-12-05 16:00:56

[FAQ14812]如何快速对系统重启问题进行归类
2015-08-31
平台...
软件分支...
FAQs 4 of 66

内容

[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_Detectwe 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的分配流程。
 
 
阅读(1336) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~