Monkey测试中卡在开机阶段的问题

1.正常情况下，当手机非第一次重启，kernel的hang_monitor 会正常启动：

2. 当手机发生FWR后，由于kernel会正常执行，所以hang_detect的机制理论上会正常工作；

// hang_detect的工作机制流程

kernel-3.18/drivers/misc/mediatek/aee/aed/monitor_hang.c

以上是在Monkey测试中发现一例卡在开机阶段的问题。分析如下：

灰屏的问题现场debug分析如下：
1. 初步分析问题原因是由于在开启过程中,启动DisplayManagerService后，去等待屏幕亮起时，由于需要与SF进行IPC通信；但SF Binder现场耗尽无法处理，导致一直卡在开机阶段;

//启动display阶段
06-06 17:44:09.958 10128 10128 I SystemServer: WaitForDisplay
06-06 17:44:19.343 10128 10140 I SystemServer: mSFTime=0
06-06 18:14:01.059 10128 10140 I SystemServer: mSFTime=0

//displayManagerService onBootPhase 阶段
06-06 17:44:09.954 10128 10128 I SystemServiceManager: Starting com.android.server.display.DisplayManagerService
06-06 17:44:09.958 10128 10128 I SystemServiceManager: Starting phase 100
    
//DisplayManagerService 添加默认display
06-06 17:44:09.954 10128 10128 I SystemServiceManager: Starting com.android.server.display.DisplayManagerService
06-06 17:44:09.965 10128 10152 I DisplayManagerService: Display device added: DisplayDeviceInfo{"Built-in Screen":
...
//循环打印，出问题点
06-07 10:44:08.368 10128 10140 I SystemServer: mSFTime=0
2. 没有触发SWT和Hang_detect的原因是 由于Watchdog此时还未注册，不能正常触发；
3. SF binder耗尽的原因是有由于Binder线程都在等锁

如上分析，根因是SF Binder耗尽，但如果触发hang_detect，手机正常重启就不会卡在开机阶段；所以该问题转为 hang_detect功能为何失效

该问题，理论上触发Hang_detect后就不会卡在开机阶段，因为重启下就会恢复正常。
发现存在一种情况并没有触发hang_detect的情况：
当fwr后，monitor hang正好检测到system_server pid的存在，就会disable hang_detect功能，且count +4 ：

static int hang_detect_thread(void *arg)
{
        while (1) {
                pr_info("[Hang_Detect] hang_detect thread counts down %d:%d, status %d.\n",
                                hang_detect_counter, hd_timeout, hd_detect_enabled);
                system_server_pid = FindTaskByName("system_server");
                //当发生FWR时，正好monitor check到这里，发现system_server_pid 不存在
                if ((hd_detect_enabled == 1) && (system_server_pid != -1)) { 
                    ...
                } else {
                      //由于是FWR，所以正常这里肯定是1，
                     if (hd_detect_enabled == 1) {
                         //count 计数 +4
                         hang_detect_counter = hd_timeout + 4;
                         //关闭hang_monitor功能
                         hd_detect_enabled = 0;
                     }
                   //每次count reset
                   reset_hang_info();
                }

Log里可以验证这点：

 count在11的基础上加4 说明走了else的逻辑，且每次都reset了count的值

<6>[427067.792783] (2)[139:hang_detect][Hang_Detect] hang_detect thread counts down 15:11, status 0.
<6>[427067.792783] (2)[139:hang_detect][Hang_Detect] hang_detect thread counts down 15:11, status 0.
<6>[427097.796111] (2)[139:hang_detect][Hang_Detect] hang_detect thread counts down 15:11, status 0.
<6>[427097.796111] (2)[139:hang_detect][Hang_Detect] hang_detect thread counts down 15:11, status 0.

解决方案：

该问题hang_detect存在这种情况，且不止一例，如果以后在kernel文件发现counts 比hd_timeout_count 大4 ，说明kick时，system_server 被重启过。

由于这块属于BSP，给出的建议有如下2种：

1 . 当检测到system_server 不存在时，继续下一次循环

system_server_pid = FindTaskByName("system_server");
+if (system_server_pid != -1) {
+continue;
+}
+if ((hd_detect_enabled == 1)) {

-  if ((hd_detect_enabled == 1) && (system_server_pid != -1)) 

 

2.去掉如下判断，因为在if条件里还会判断hang_detect的超时机制，还会触发hang_detect 

+if ((hd_detect_enabled == 1)) {

-  if ((hd_detect_enabled == 1) && (system_server_pid != -1)) 

方案由BSP 评估合入。