Android稳定性 - 云栖梦泽

[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。

linux-dead-lock-detect-lockdep

本文主要介绍了死锁概念、AB-BA死锁的形成、Linux中的lockdep死锁检测模块及其使用实例。摘要：死锁是指多个进程因为长久等待已被其他进程占有的资源而陷入阻塞的状态。Linux中的lockdep模块可以检测死锁，它通过跟踪锁类之间的依赖关系来工作。文章介绍了死锁的概念，分析了AB-BA死锁的形成原因，并给出了lockdep的使用实例，说明了如何通过lockdep检测和修复死锁问题。

[Android稳定性] 第044篇 [问题篇] Unable to handle kernel write to read-only memory at virtual address

一、问题现象老化测试时出现黑屏现象， 9/12：今天已经确认的现象使用9-11的版本 72台机器出现27 个黑屏，其中25个为USB问题引起的dump（2个是电量低关机），通过LOG分析是在老化45次重启测试的时候出问题（45次重启1个半小时），9-11版本带了高通的等待probe完成 wai

[Android稳定性] 第042篇 [问题篇] 数组越界导致的Unexpected kernel BRK exception at EL1

在reboot压力测试中，一台设备出现死机，死机类型为Unexpected kernel BRK exception at EL1，发生在CPU7上的fg_mac_read_block函数。通过分析内核调用跟踪和源码，发现死机是由于fg_checksum函数中的数组越界引起的。具体来说，t_len没有做范围限制，导致在t_buf[35]大于42时，访问t_buf数组越界。解决方案是在t_len大于42时将其限制为42。此外，分析还发现不能完全相信trace32解析处的变量结果，某些情况下需要根据寄存器值来推导实际值。此外，编译器优化也对代码执行产生了影响，例如在某些情况下直接将结果赋值给寄存器，不再运行时计算。