MTK 驱动（38）---MTK 待机问题分析

mtk 平台待机问题分析:

1 待机问题分类 

1）无法待机： 

1. 需要确认 APK 是否有 partial_wakelock 

2. kernel 是否持有 wakeup source 不释放. 

2）可以待机，但是唤醒频繁. 

1. 是否有打开数据连接，或者 wifi(网络包唤醒) 

2. 如果不是 1，一般是 alarm 或者网络注册，modem CLDMA 的一些唤醒. 

常见的唤醒：EINT/CLDMA/PCMTIMER/CONN/CCIF 

2 抓 log 注意事项: 

1.处理待机问题，需要提供 mobile log and netlog(如果有打开数据连接或者 WIFI), 在问题没有指向是modem 的问题前，不要打开 modem log. 

2.手机先对准网络时间，并提供测试开始跟结束的时间 以及电流波形图(电流图跟 1 的 mobile log 是一起运行)，MTK 处理一般是使用 PowerMonitor. 

方案一：log 设定成开机自启动，并在开机后直接测试. 

测试结束后： 

adb shell dumpsys batterystats > battersystats.log 

adb shell cat /sys/kernel/debug/wakeup_sources > wakeup_sources.log 

adb shell ps > ps.txt 

方案二： 

测试前 

adb shell dumpsys batterystats > battersystats_1.log 

adb shell cat /sys/kernel/debug/wakeup_sources > wakeup_sources_1.log 

测试后： 

adb shell dumpsys batterystats > battersystats_2.log 

adb shell cat /sys/kernel/debug/wakeup_sources > wakeup_sources_2.log 

adb shell ps > ps.txt 

大部分情况下，如果是因为持锁的问题，很容易把 sys log 前面的持锁的 log 冲掉.所以一般建议从开机启动后测试，测试时间不用太长.如果特殊情况，重启后不复现，请使用方案二.

3.分析问题

3.1如何确认唤醒源

正则表达式： \[([^p]+)\]\[SPM\] wake up by|md_settle|suspend exit

<2>[ 158.453122]<1>-(0)[95:kworker/u8:2][SPM] wake up by CONN2AP, timer_out = 10217, r13 =0x47000, debug_flag = 0x9c

 <2>[ 158.895650]<3>-(0)[95:kworker/u8:2][SPM] wake up by CONN2AP, timer_out = 80686, r13 =0x2004f208, debug_flag = 0x9f 

<2>[ 162.544639]<2>-(0)[141:kworker/u8:3][SPM] wake up by CONN2AP, timer_out = 7546, r13 =0x20047238, debug_flag = 0x9c 

<2>[ 162.983046]<2>-(0)[141:kworker/u8:3][SPM] wake up by EINT, timer_out = 113643, r13 =0x20041238, debug_flag = 0x9f 

<2>[ 163.964958]<2>-(0)[141:kworker/u8:3][SPM] wake up by CONN2AP, timer_out = 5112, r13 =0x47000, debug_flag = 0x9c 

<2>[ 169.662402]<0>-(0)[142:kworker/u8:4][SPM] wake up by CLDMA_MD, timer_out = 1452520, r13 =0x41238, debug_flag = 0x9f 

3.2.如何确认唤醒的时间点(基本上都适用)

正则表达式：kworker.*\]\[SPM\] wake up by|md_settle|suspend exit，可以搜索到具体的唤醒时间点：

 【前缀不是 swapper】wake up by 是系统起来的第一句 log，时间会开始重新 running，往下第一个 PM:suspend exit 基本上就是唤醒的时间点. 

<6>[ 2971.418367]<0>-(0)[0:swapper/0][SPM] wake up by GPT, timer_out = 302, r13 = 0x20041238,debug_flag = 0x90 

<2>[ 172.168900]<0>-(0)[142:kworker/u8:4][SPM] wake up by CONN2AP, timer_out = 4561649, r13 =0x20047238, debug_flag = 0x9f 

<6>[ 172.239721]<1> (1)[142:kworker/u8:4]PM: suspend exit 2015-12-27 03:09:37.021819616 UTC 

<2>[ 172.612907]<1>-(0)[142:kworker/u8:4][SPM] md_settle = 99, settle = 99 

<2>[ 172.612907]<1>-(0)[142:kworker/u8:4][SPM] wake up by CONN2AP, timer_out = 19411, r13 =0x20047238, debug_flag = 0x9c 

<6>[ 172.679674]<1> (3)[142:kworker/u8:4]PM: suspend exit 2015-12-27 03:09:38.023614769 UTC 

<6>[ 172.948171]<1> (3)[142:kworker/u8:4]PM: suspend exit 2015-12-27 03:09:38.292113615 UTC 

<2>[ 176.028364]<3>-(0)[95:kworker/u8:2][SPM] md_settle = 99, settle = 99 

注意这个是 kernel 的时间，转换到 main log 的时间：根据 mobile log 里面 properties 的时区信息[persist.sys.timezone].譬如[persist.sys.timezone]: [Asia/Shanghai] 即需要加上 8 个小时 

2015-12-27 03:09:37.021819616 对应的 UTC 时间为：2015-12-27 11:09:37.021819616

3.3 常用唤醒

其中一次完整的唤醒有如下的 log: 

//第一句唤醒,wake up by CONN2AP，代表被 connectivity wakeup，大部分情况是 WIFI 数据.<2>[ 172.612907]<1>-(0)[142:kworker/u8:4][SPM] wake up by CONN2AP, timer_out = 19411, r13 =0x20047238, debug_flag = 0x9c 

//唤醒的时间点： 

<6>[ 172.679674]<1> (3)[142:kworker/u8:4]PM: suspend exit 2015-12-27 03:09:38.023614769 UTC 

<6>[ 172.948171]<1> (3)[142:kworker/u8:4]PM: suspend exit 2015-12-27 03:09:38.292113615 UTC 

<6>[ 173.572666]<1> (0)[142:kworker/u8:4]PM: suspend exit 2015-12-27 03:09:38.916604538 UTC 

<6>[ 173.989622]<3> (1)[142:kworker/u8:4]PM: suspend exit 2015-12-27 03:09:39.333548769 UTC 

<6>[ 174.399687]<3> (3)[142:kworker/u8:4]PM: suspend exit 2015-12-27 03:09:39.743622615 UTC 

//最后一句 sleep 的 log. 只有出现 md_settle 才代表真正 sleep. 

<2>[ 176.028364]<3>-(0)[95:kworker/u8:2][SPM] md_settle = 99, settle = 99 

2015-12-27 03:09:38.023614769 对应的 main log 时间为：2015-12-27 11:09:38.023614769

确认引起唤醒的问题包： 

在 main log 里面搜索关键字：Posix_connect Debug： 

可以发现对应的时间点，是豌豆荚这个应用在发包. 

【下面的 log 代表是那些 APK 在发包，有发包就有收包】 

12-27 11:05:44.279 2895 3138 D Posix : [Posix_connect Debug]Process com.lava:pushservice :80 

12-27 11:06:02.786 4715 4778 D Posix : [Posix_connect Debug]Process com.sina.weibo :443 

12-27 11:06:07.779 4715 4798 D Posix : [Posix_connect Debug]Process com.sina.weibo :443 

12-27 11:06:10.080 4827 4917 D Posix : [Posix_connect Debug]Process com.sina.weibo:remote :4828 

12-27 11:06:15.465 4827 4917 D Posix : [Posix_connect Debug]Process com.sina.weibo:remote :4828 

12-27 11:09:38.313 3635 3670 D Posix : [Posix_connect Debug]Processcom.wandoujia.phoenix2:update_service :44312-27 11:09:42.347 4827 4917 D Posix : [Posix_connect Debug]Process com.sina.weibo:remote :4828 

12-27 11:09:49.055 4827 4917 D Posix : [Posix_connect Debug]Process com.sina.weibo:remote :4829 

12-27 11:09:4 9.111 4827 4942 D Posix : [Posix_connect Debug]Process com.sina.weibo:remote :80 

12-27 11:09:51.199 3495 3570 D Posix : [Posix_connect Debug]Process com.wandoujia.phoenix2 :80 

并非每个 wake up 的时间点，都可以找到明确的 APK 在发送包. 

参考【如何确认具体一次唤醒，是哪个 APK 引起的】

【唤醒类型为 CLDMA_MD】 

正则表达式：\[([^p]+)\]\[SPM\] wake up by|CLDMA_MD wakeup source|md_settle|suspend exit 

确认唤醒的 channel ID： 

<2>[ 3072.796534]<2>-(0)[14284:kworker/u8:0][SPM] wake up by CLDMA_MD, timer_out = 5598687, r13= 0x20001238, debug_flag = 0x9f

 //唤醒点之后第一句 CLDMA_MD wakeup source 会打印出 channel ID. 譬如该题是 10

<5>[ 3072.810528]<2> (1)[23510:kworker/u9:0][ccci1/mcd]CLDMA_MD wakeup source:(1/10) 

<6>[ 3072.872362]<3> (1)[14284:kworker/u8:0]PM: suspend exit 2016-02-05 11:28:18.030905923 UTC 

<6>[ 3074.000405]<2> (0)[14284:kworker/u8:0]PM: suspend exit 2016-02-05 11:28:19.158954462 UTC 

<2>[ 3075.262223]<3>-(0)[14284:kworker/u8:0][SPM] md_settle = 99, settle = 99 

<2>[ 3075.262223]<3>-(0)[14284:kworker/u8:0][SPM] wake up by EINT, timer_out = 4159454, r13 =0x41000, debug_flag = 0x9f 

<6>[ 3075.341978]<3> (1)[14284:kworker/u8:0]PM: suspend exit 2016-02-05 11:30:28.031774693 UTC 

<2>[ 3075.996184]<2>-(0)[14284:kworker/u8:0][SPM] md_settle = 99, settle = 99

常用的唤醒的 channel： 

[channel 10]： 

需要搜索 radio log 确认是什么 AT command 唤醒了系统. 

时间点: 

2016-02-05 11:28:18.030905923 + 8h = 2016-02-05 19:28:18.030905923 

以 19:28:18 搜索 radio log，往下搜索，找到第一条 AT<02-05 19:28:18.032 20835 20856 D AT : AT< +CIREPI: 0

 说明唤醒的 AT command 是 AT< +CIREPI

常见的 AT command 的唤醒：参考下面【常见 AT 命令解析】

AT +ECOPS

搜网的次数 ------------> AT: CREG CGREG (一个是 CS，一个是 PS) 

网络 PDP 状态变化的次数 ----------> AT：CGEV (PDN activate/deactivate) 

VOLTE 功能导致唤醒的次数 -----------> AT: CIREPI CIREPH CNEMS1 CIREG EIMS 

LTE 数据连接 ------------> AT: EDRBSTATE 

[channel 14]

 一般是跟 channel10 一起产生，modem 小区消息变化，会记录小区的信息到 nvram.