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 评估合入。

你可能感兴趣的:(Monkey测试中卡在开机阶段的问题)