系统自动重启异常-总结网上看到的博文

watchdog timeout 有两种，一种是cpu的watchdog timeout，称为HWT（hardware timeout），SWT（software timeout）。

监测cpu的watchdog主要是监测cpu是否卡死，cpu喂狗间隔是20s，而超时时间是30s，也就是说最长能容忍卡住的时间是10s（卡一小会还是可以的），超过这个时间，系统就会复位了。这里还有问题，由于喂狗进程之间没有同步，是否有可能存在刚开始一起喂狗，之后渐渐出现先后呢？误差肯定有的，但在任何30s时间里，喂狗进程都会喂1次狗的（因为喂狗间隔20s，每个CPU肯至少会喂1次狗）。而只要CPU卡死超过10s就复位了。

 

 

异常分析之SWT

 

SWT是指Android Watchdog Timeout，应用层看门狗超时，通常我们说的WDT（Watchdog Timeout）是HWT，硬件看门狗超时。应用层Watchdog主要实现是在frameworks/base/services/java/com/android/server/Watchdog.java里，其实现原理看看这个类就知道，主要逻辑是：

1. Watchdog是单例模式，监控系统几个比较重要的Service，如：MountService、ActivityManagerService、InputManagerService等，这些Service在启动时通过调用Watchdog.getInstance().addMonitor(this); 加入到Watchdog的监控列表中。在ActivityManagerService实现的Watchdog的抽象方法：

/** In this method we try to acquire our lock to make sure that we have not deadlocked */
    public void monitor() {
        synchronized (this) { }
    }

因为在AMS中，很多操作需要线程安全，且使用ActivityManagerService实例的monitor作为锁，所以一个判断service是否有卡死的重要手段就是去看是否能获取到ActivityManagerService实例的monitor，如果长时间获取不到(即看门狗线程没有从monitor方法返回)，就说明很可能卡死了。

可以使用QAAT去分析log，实践证明并不能把所有有用的信息抓出来，还是得自己去细看。分析时需要把所有log都放到QAAt.bat的目录下。

WDT ：watchdog timer

 

重启和死机问题比较关键的信息是重启开机时抓取的log，而不是重启前的log。

Warning: No aee db file or trace file!!!
Please pull aee db file: /data/aee_exp or /sdcard/mtklog/aee_exp
Please pull trace info: /data/anr
[温馨提醒 - 关于死机与重启的问题处理]
1. 请自开机起全程录制Mobile log与UART4 log信息,片段或事后的log无益于问题的排查
2. 请参考客户文档步骤完整提交sdcard/mtklog, data/aee_exp, data/anr文件夹

 

hang detect：这个检测watchdog运行异常的程序：一个用来监控system server 的watchdog 行为是否异常

 

即在hang detect 中有两个关键的变数， hd_detect_enabled 指示当前hang detect 是否开启， hang_detect_counter 为计时器计数. hang_detect thread 每隔30s (HD_INTER) 将其减一。

其设计思想非常简单，即上层通过ioctl 此device, 设置hang_detect_counter, 即告知hang detect, 本人预计会在hang_detect_counter * 30s 之内再次来tick 您, 假如我没有在这个时间内tick 您，那么就意味着我已经牺牲了, 您就发动暴动, 重启手机.

对应hang_detect_thread 的实现就这个循环检测和操作hang_detect_counter .

 

 

 

即System server watchdog 在轮转的过程中，会周期性的tick hang detect, 目前设计的timing 比较保守，我们会在M 版本将这个时间进一步降低优化. tick 分成三种:

1. 正常情况下，tick 300s, 对应count=10.
2. 在dump backtrace 时，tick 600s, 对应count=20.
3. 在SWT 发生的情况下，tick 720s, 对应count=24.

这个可以从kernel log 中明确的看到.如：

watchdog 看起来正常：
    [  198.215932] (1)[1322:watchdog]AEEIOCTL_RT_MON_Kick ( 300)  
    [  198.215945] (1)[1322:watchdog][Hang_Detect] hang_detect enabled 10 

watchdog 在dump backtrace:

    [  258.218145] (0)[1322:watchdog]AEEIOCTL_RT_MON_Kick ( 600)  
    [  258.218171] (0)[1322:watchdog][Hang_Detect] hang_detect enabled 20  

 watchdog 在做SWT:

    [  299.046542] (0)[1322:watchdog]AEEIOCTL_RT_MON_Kick ( 720)  
    [  299.046572] (0)[1322:watchdog][Hang_Detect] hang_detect enabled 24  

当然你也可以从hang detect thread 的log 中看到这个：
    [  210.475572] (0)[90:hang_detect][Hang_Detect] init found pid:1.  
    [  210.475735] (0)[90:hang_detect][Hang_Detect] mmcqd/0 found pid:158.  
    [  210.475815] (0)[90:hang_detect][Hang_Detect] surfaceflinger found pid:265.  
    [  210.475887] (0)[90:hang_detect][Hang_Detect] system_server found pid:734.  
    [  210.475919] (0)[90:hang_detect][Hang_Detect] ndroid.systemui found pid:1071.  
    [  210.476003] (0)[90:hang_detect][Hang_Detect] debuggerd found pid:4313.  
    [  210.476027] (0)[90:hang_detect][Hang_Detect] debuggerd64 found pid:4314.  
    [  210.476056] (0)[90:hang_detect][Hang_Detect] hang_detect thread counts down 10:10.  
 

 

 

 

 

Android异常分析： 这文章对于初学者入门有点用

 

 

Hang Detect 问题分析案例

 

Hang Detect 问题

 

 

 

 

以下是该博文http://blog.csdn.net/sssheiye/article/details/50205041的主要信息：

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