![[Android稳定性] 第046篇 [方法篇] 如何使用trace32恢复AOP现场?](https://halo-1259291793.cos.ap-shanghai.myqcloud.com/2025/06/a1dmnee.png?imageView2/0/w/800)
[Android稳定性] 第046篇 [方法篇] 如何使用trace32恢复AOP现场?
这篇文章介绍了使用hansei工具解析AOP/RPM以及使用trace32恢复AOP现场的过程,包括工具的获取、安装依赖库、执行工具、恢复前的准备工作以及恢复操作。
![[Android稳定性] 第045篇 [问题篇] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00](https://halo-1259291793.cos.ap-shanghai.myqcloud.com/2025/06/lbivwl4.png?imageView2/0/w/800)
[Android稳定性] 第045篇 [问题篇] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
在测试DDR TT和Reboot测试专项过程中,机器出现了多次dump,且dump根因相同。通过分析panic现场,发现是由于UFS初始化失败导致的。具体来说,是在`ufshcd_complete_dev_init`函数中,对`fDeviceInit`标志的轮询超时,导致无法挂载必要的分区,最终引发panic。 为了进一步定位问题,我们在`ufshcd_complete_dev_init`函数中添加了debug patch,增加了时间戳计算和日志输出。通过新的dump分析,发现异常发生在轮询`fDeviceInit`标志的过程中,时间从2.25秒突然跳到了7.15秒,中间没有日志输出,表明存在长时间阻塞。 通过trace32分析,发现一个名为`kworker/6:1`的线程出现了明显的异常,执行时间长达4386毫秒。进一步分析该线程的栈和寄存器信息,发现其最后一次执行的函数是`kfree_rcu_monitor()`,即用于回收内存的后台回调。结合CPU栈分析,发现大部分CPU都在执行串口输出相关的函数,如`qcom_geni_serial_poll_tx_done`。 综合以上分析,根本原因是UFS函数执行时被高优先级的串口输出调度出去。串口输出在持锁状态下运行,不允许调度,直到输出结束;同时,阻塞式串口写函数会主动spin等待硬件完成,长时间占用CPU,导致UFS函数无法正常执行,最终引发panic。