目录
1:简介
2:怎么抓取和分析log
3:怎么确定问题点
简介 系统稳定性目前主要是解决系统死机重启。 分为两部分:Android /kernel Kernel 分析需要的文件和工具: Mtklog, vmlinux ,gat工具,解析vmlinux的脚本。
Vmlinux路径:alps\out\target\product\k55v1_64_op01_pre\obj\KERNEL_OBJ
解析vmlinux的脚本
ARM 32位版本:prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/
ARM 64位版本:prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/
Log抓取
1:如果能正常开机,通过*#*#3646633#*#*抓取mtklog,出现异常的时候会生成文件夹aee**,如
2:如果不能正常开机,需要抓取串口log. 另外默认把串口一直打开的话,可以修改代码:
alps\kernel-3.10\drivers\misc\mediatek\mtprof\mt_printk_ctrl.c
nt mt_need_uart_console = 0;->1
3:如果ADB能正常起来,但开不了机,可以通过ADB命令来抓取相关的log. Usr 版本只能抓取logcat
确认问题点
Case 1: 能开机,卡死在一些界面上。
----这种情况,有几个步骤:先按power键看是否可以正常休眠唤醒。如果power键有反应,再插USB,看是否可以正常检测到ADB,如果可以正常检测到ADB,那可以通过ADB shell getevent 来看是否是TP驱动没有报点。
Case 2 开机卡死,按power键没反应。
----需要抓取mtklog,看是否有生成aee的log文件夹,有的话需要通过gat工具来解析。步骤如下: 1:电脑端打开应用程序 gat-linux-x86_64-3.1501.1.c\gat-linux-x86_64-3\modules\MediatekLogView\MediatekLogView
2:打开aee目录里面的文件,如” db.fatal.06.KE.dbg“,可以直接拖进来。
Case 3 不能开机,需要抓取串口log分析。
简单分析步骤: 1:抓取串口log[MTK 的波特率需要设置为921600]
2:确认PC指针指到具体函数和具体函数
在alps/prebuilts/gcc/linux-x86/aarch64-linux-anroid-4.9/bin$./aarch64-linux-android-addr2line -e vmlinux -f -C 0xffffffc0009f62a4
确定具体文件和行号
alps/prebuilts/gcc/linux-x86/aarch64-linux-anroid-4.9/bin$./aarch64-linux-android-objdump -d vmlinux
3:有时候kernel看到了异常,但不一定就是kernel的问题,有可能是上层主动发了重启之类的命令,可以在log中看类似的打印:
Case 4: WatchDog超时
Case 5 HW reboot
Hardware reboot的成因:MT6592平台芯片有一个External watch dog,软件每隔30秒要去踢一次,若没有踢到,就会触发软件Watch Dog Timeout重启;
若软件有在规定的时间内(30秒)去踢这个External Watch Dog,但是由于硬件原因,导致External Watch Dog没有及时被踢到,那么这个External Watch Dog最多会等待60秒的时间,60秒之后会直接触发硬件重启,这就是所谓的Hardware reboot
至于是什么样的硬件原因导致无法及时提到External Watch Dog,最常见的一种是bus hang住, 比如不合理的读写寄存器就会导致bus hang住;也有一些是硬件设计不合理,或者硬件出现故障导致机器乱死,或者硬件某些器件不稳定,导致Hardware reboot 如果是因为读写寄存器导致bus hang住,进而触发Hardware reboot,一般在last pc 和last kmsg中会有体现,每次最后的PC或者最后打印出来的几句log都是一样或者相似的 若是硬件不合理或者硬件出现故障或者硬件不稳,这种在last pc 和last kmsg中就没有规律性了, 这种case,一般都是对照之前的项目,看之前项目是否有出现? 若之前项目稳定,而现在项目有Hardware reboot,则对照之前项目跟现在项目在硬件上的差异,然后通过硬件实验来理清问题