目录
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，则对照之前项目跟现在项目在硬件上的差异，然后通过硬件实验来理清问题