阅读 1572

手机重启问题快速分析定位指南

极力推荐文章:欢迎收藏 Android 干货分享

#####阅读五分钟,每日十点,和您一起终身学习,这里是程序员Android

本篇文章主要介绍 Android 开发中的部分知识点,通过阅读本篇文章,您将收获以下内容:

一、 AEE 系统机制简介 二、AEE 重启异常分类介绍 三、重启问题快速分析归类指南之 Kernel Exception 四、重启问题快速分析归类指南之 Watchdog Timeout 五、重启问题快速分析归类指南之 Hardware Reboot

#一、 AEE 系统机制简介

1.MTK AEE 系统

AEEMTK平台自研,用于侦测Android手机系统异常重启的一套系统机制,当AEE系统 侦测到异常后会生成 db 文件.

2.db 文件存储路径
/data/aee_expdata/vendor/mtklog/aee_exp

Android 8.0 之后由于系统安全机制导致db无法保存到MTK loguser版本 中AEE仅仅侦测引起的重启故障,例如:KE/system server , NE/system server ,JE/SWT

3.AEE 异常侦测机制

AP层重启时候,AEE系统会在db生成后会发生am 广播(com.mediatek.log2server.EXCEPTION_HAPPEND),但系统重启类异常(KE / HW reboot/ HWT)不会发送广播,因为AMS还无法使用。

另外,AEE会开机后判断异常重启,当异常重启后会设置debug.mtk.aee.dbproperty,由于不是persist的,关机就丢失,因此只有异常重启后才有这个property存在。

因此,我们可以通过检查debug.mtk.aee.db的方法来获取系统是否发生了异常重启。

4.重启异常 debug.mtk.aee.db 读取方法

  • 1.java 层:

android.os.SystemProperties.get("debug.mtk.aee.db", "")

    1. native层:

int property_get(const char* key, char* value, const char* def);

    1. 通过adb shell

adb shell getprop debug.mtk.aee.db

二、AEE 重启异常分类介绍

AEE 重启异常分类 如下:

  • 1.KE
  • 2.HWT
  • 3.HWT Reboot
  • 4.NE
  • 5.JE
  • 6.SWT

上面的类型可能会变化,具体请参考kernel代码:kernel-4.4/drivers/misc/mediatek/include/mt-plat/aee.h里的AE_EXP_CLASS

1.AEE 输出内容

当有异常发生时候,会生成dbg文件,通过特殊的工具可以解压这个dbg文件。

关注微信公众号程序员Android 回复 aee 即可获取解析重启db log的工具。

关注微信公众号:程序员Android
回复  aee 即可获取解析工具

2.dbg文件

db.fatal.00.JE.dbg.DEC 这个文件夹使用aee_extract.exe抽取aee db压缩文件生成的,这个工具在gat-win32-3\prebuilt\spsstools\bin\aee_extract.exe可以找到。

db 文件解压后部分内容

3.ZZ_INTERNAL 简介

ZZ_INTERNAL 包含重启的简单信息,如需获取更多信息,需要解压dbg文件。

ZZ_INTERNAL

4.KE、JE、NE、SWT分类

这种类型最好分类,因为有调用栈,有进程名,分类可以做的很细致。

KE db如果存在SYSTRACKER_DUMP文件,表示存在bus hang,也可以单独列出来。

5. HWT分类

不能以当前CPU的调用栈分类。因为最后调用BUGCPU是随机的。同样的调用栈,可能是不同的root cause,应该按卡住的CPU的调用栈进行分类

SYS_LAST_KMSGKick bit、check bit得出无喂狗CPU,可能存在多个或没有。 从SYS_LAST_KMSG提取无喂狗CPU的调用栈

6.HW reboot分类

可以通过__exp_main.txt里的Exception Type分类

  • HW reboot
  • Thermal reboot
  • SPM reboot
  • ATF crash

TypeHW reboot可以进一步细分( 按SYS_REBOOT_REASON里字段信息 )

  • last pc,看各个Core停止的位置

  • deepidle/sodi3/sodi/spm_suspend,如果非0表示当时处于low power场景

    1. Android Dropbox

三、重启问题快速分析归类指南之 Kernel Exception

当手机重启时候,Kernel重启异常信息会保存在手机/data/aee_expdata/vendor/mtklog/aee_exp 中的db文件中。

Kernel Exception重启分类如下:

  • 1.Kernel Panic
  • 2.Watchdog Timeout
  • 3.Hardware Reboot

1.Kernel Panic

Linux kernel发生了无法修复的错误,从而导致 panic。通过查看 SYS_KERNEL_LOG 的内容.

kernel Panic 进一步可以分为如下几类:

    1. 普通的data abort
    1. oom主动触发的panic
  • 3.undefined instruction,未定义指令异常
  • 4.bad mode异常,即PC处于一个无效的virtual address

###1. 普通的data abort

SYS_KERNEL_LOG中,可以检索到如下关键信息: Unable to handle kernel NULL pointer dereference at virtual address XXXXXXXX 如上的XXXXXXXX代表某个非法地址。这种类型是最多的。

2. oom 主动触发的panic

SYS_KERNEL_LOG中,可以检索到如下关键信息: Kernel panic - not syncing: Out of memory and no killable processes...

此种类型的panic一般是某个process或者APK耗尽了memory资源,从而kernel主动触发的panic重启。

3.undefined instruction,未定义指令异常

SYS_KERNEL_LOG中,可以检索到如下关键信息:

Internal error: Oops - undefined instruction

此类异常较为少见,可能是CPU/DRAM 不稳定或者受干扰导致的问题。

4.bad mode异常,即PC处于一个无效的virtual address

SYS_KERNEL_LOG中,可以检索到如下关键信息: Bad mode in Synchronous Abort handler detected [14820.652408]-(1)[682:VSyncThread_0][<ffffffc000088f90>] bad_mode+0x78/0xb0 此类异常较为少见,可能的原因是stack错乱,或者未注册回调函数引起。

四、重启问题快速分析归类指南之 Watchdog Timeout

看门狗超时有两种

  • 1.底层看门狗超时HWT
  • 2.上层hang_detect 触发看门狗超时SWT

###1.底层看门狗超时HWTSYS_KERNEL_LOG中,可以检索如下关键信息

  • arm64 平台
PC is at aee_wdt_atf_info+0x4c8/0x6dc
LR is at aee_wdt_atf_info+0x4c0/0x6dc
复制代码
  • arm32 平台
PC is at aee_wdt_irq_info+0x104/0x12c
LR is at aee_wdt_irq_info+0x104/0x12c
复制代码

此类异常较为常见,多见于底层频繁irq/bus卡死,导致kicker无法被schedule,从而引起watch dog触发中断,引导系统进入FIQ处理流程,最终callBUG触发重启。

###2. 上层hang_detect 触发看门狗超时SWT

SYS_KERNEL_LOG中,可以检索( 关键字 :hang_detect)

[ 2131.086562] (0)[77:hang_detect][Hang_Detect] we should triger HWT ...
                                    ...
 
[ 2180.467416]-(0)[77:hang_detect]PC is at aee_wdt_irq_info+0x154/0x170

[ 2180.467426]-(0)[77:hang_detect]LR is at aee_wdt_irq_info+0x154/0x170
                                     ...
复制代码

此异常类型较为常见,多见于GPU/SD卡/eMMC无法满足surfacelinger/system_server的通讯需求,从而导致上层卡死,进而主动触发看门狗超时重启

#五、重启问题快速分析归类指南之 Hardware Reboot

Hardware rebootwatch dog直接发出reset信号,导致整个系统重启;在重启之前,并没有触发任何异常处理流程。

一般情况下,hardware reboot对应的db不会有SYS_KERNEL_LOG 可以排查,只能从SYS_LAST_KMSG获知异常之前kernel的动作,以及从SYS_REBOOT_REASON获知异常时的CPU寄存器值和其它参数。

ZZ_INTERNAL 档案,可以知道发生了hardware reboot 例如 如下部分logHardware Reboot,0,0,99,/data/core/,0,,HW_REBOOT,Fri Jul 3 14:31:53 CST 2015,1 至此,本篇已结束,如有不对的地方,欢迎您的建议与指正。同时期待您的关注,感谢您的阅读,谢谢!

微信关注公众号:  程序员Android,领福利

文章分类
Android
文章标签