Android稳定性 60篇

linux/android稳定性文章

[Android稳定性] 第048篇 [原理篇] Android SWT机制介绍 2月前查看 评论
[Android稳定性] 第048篇 [原理篇] Android SWT机制介绍

SWT-Android Software Watchdog Timeout 是 Android 系统中的一种监控机制，用于检测 System Server 进程中的核心服务和线程是否卡住，并在必要时自动重启系统。本文介绍了 SWT 的原理、实现方式、常见原因、检查流程以及相关工具的使用。 **SWT 的重要性**： System Server 是 Android 系统的核心进程，为应用程序提供各种服务。如果 System Server 中的核心服务和线程卡住，会导致系统出现各种异常，例如手机卡顿、应用程序无法启动等。SWT 机制可以及时发现并解决这些问题，提高系统稳定性。 **SWT 的实现**： SWT 通过添加 MonitorChecker 和 HandlerChecker 两种 Checker 来监控核心服务和线程。MonitorChecker 检查系统核心服务是否被锁时间过长，HandlerChecker 检查系统核心线程创建的 Looper 管理的消息队列是否阻塞。如果检测到卡顿，SWT 会杀死 System Server 进程并重启系统。 **常见 SWT 原因**： 等锁、SurfaceFlinger 卡住、Native 方法执行时间过长、Binder Server 卡住、Zygote fork 进程时卡住、Dump 时间过长等。 **SWT 检查流程**： 检查 SWT DB 中的 trace 文件，分析线程状态、call stack 和相关 log，找出卡顿的原因。 **相关工具**： hang_SWT_analysis-v6.1 工具可以自动分析 SWT DB，并生成分析报告。 **性能问题导致的 SWT**： 检查 CPU Loading、Low Memory 和 IO 状况，找出性能瓶颈并进行优化。

[Android稳定性] 第045篇 [问题篇] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 2月前查看 评论
[Android稳定性] 第045篇 [问题篇] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

本文分析了在测试DDR TT和Reboot测试专项过程中机器出现dump的问题。通过panic现场和加debug patch的分析，发现死机原因是ufs没有初始化成功，函数`ufshcd_complete_dev_init`耗时过长。进一步分析发现，`kworker/6:1`线程在执行`kfree_rcu_monitor()`时被调度出去，并长时间卡在`schedule()`中，最终导致死机。根本原因是在ufs函数执行时被串口输出调度出去，而串口输出调度优先级很高，执行console_unlock()时持锁状态下运行，不允许调度，且阻塞式串口写函数`qcom_geni_serial_poll_tx_done`会造成长时间占用CPU。

linux-dead-lock-detect-lockdep 2月前查看 评论
linux-dead-lock-detect-lockdep

**死锁概念**：死锁是指多个进程（线程）因等待已被其他进程占有的资源而陷入阻塞的状态。死锁一旦发生，程序本身无法解决，只能依靠外部力量使程序恢复运行。Linux 提供了检测死锁的机制，主要分为 D 状态死锁和 R 状态死锁。 **死锁类型**： * **D 状态死锁**：进程等待 I/O 资源无法得到满足，长时间处于 TASK_UNINTERRUPTIBLE 睡眠状态。触发成因复杂多样，可能因为 synchronized_irq、mutex lock、内存不足等。 * **R 状态死锁**：进程长时间处于 TASK_RUNNING 状态垄断 CPU 而不发生切换，导致多 CPU 间互锁，整个系统无法正常调度。 **常见错误**： * AA: 重复上锁 * ABBA: 曾经使用 AB 顺序上锁，又使用 BA 上锁 * ABBCCA: 这种类型是 ABBA 的扩展。AB 顺序 , AB 顺序，CA 顺序。 * 多次 unlock **AB-BA 死锁的形成**：假设有两处代码都要获取两个锁（lockA 和 lockB），如果进程 P 持有 lockA 后再去获取 lockB，而此时恰好由进程 Q 持有 lockB 且它也正在尝试获取 lockA，那么此时就是处于死锁的状态。 **lockdep 死锁检测模块**：lockdep 是 Linux 内核中的一种死锁检测机制，通过跟踪锁类的使用历史状态和依赖关系，以确保锁类状态和锁类之间的依赖总是正确的。lockdep 会检测并报告死锁风险，并提供相应的出错处理机制。 **检查规则**： * 单锁状态规则：一个软中断不安全的锁类也是硬中断不安全的锁类。 * 多锁依赖规则：同一个锁类不能被获取两次，不能以不同的顺序获取两个锁类，同一个锁实例在任何两个锁类之间，嵌套获取锁的状态前后需要保持一致。 **使用实例**：Lockdep 检测到死锁风险时，会打印相应的风险提示，并建议开发者修复代码，避免死锁。

[Android稳定性] 第044篇 [问题篇] Unable to handle kernel write to read-only memory at virtual address 2月前查看 评论
[Android稳定性] 第044篇 [问题篇] Unable to handle kernel write to read-only memory at virtual address

在老化测试中，多台机器出现黑屏问题，主要现象为使用9-11版本时，27台机器中有25台因USB问题导致dump，且问题多出现在使用33瓦充电器时。通过LOG分析，问题出现在45次重启测试中。dmesg日志显示，问题源于内存异常踩踏，具体为操作了空指针地址的结构体成员。 根本原因分析表明，在dwc3_msm模块中，存在一个空指针赋值操作，导致数据写入异常地址。解决方案建议对涉及空指针的代码进行兼容性处理，并在gerrit上提交了相关代码修改。

[Android稳定性] 第042篇 [问题篇] 数组越界导致的Unexpected kernel BRK exception at EL1 2月前查看 评论
[Android稳定性] 第042篇 [问题篇] 数组越界导致的Unexpected kernel BRK exception at EL1

在reboot压力测试中出现一台设备死机，分析发现是由于函数 `fg_mac_read_block` 在处理数据时，没有对数组长度进行范围限制，导致数组越界，触发 `Unexpected kernel BRK exception at EL1` 异常，最终导致设备死机。通过分析汇编代码和寄存器状态，确定问题根源并提出了修复方案，即在读取数据后增加对长度的判断，防止数组越界。同时，引申出对 `trace32` 解析结果和编译器优化行为的思考，强调了在实际调试中应结合寄存器状态进行分析，并注意编译器可能进行的优化。

[Android稳定性] 第041篇 [问题篇] Unable to handle kernel paging request at virtual address 00046ffca9037bf9 3月前查看 评论
[Android稳定性] 第041篇 [问题篇] Unable to handle kernel paging request at virtual address 00046ffca9037bf9

您好，根据您提供的信息，我总结了以下内容： **问题现象**：设备在系统休眠过程中出现死机。 **分析步骤**： 1. **初步定位模块**：问题出现在系统休眠过程中，设备陆续suspend，出问题的dev为disp_feature/disp-DSI-0。suspend流程中，disp-DSI-0的class被注销。 2. **第一个问题点**：display的初始化流程被电源键的中断触发函数触发，而没有走正常的display流程。 3. **第二个问题点**：`mi_disp_core_deinit`函数中，`class_destroy(g_disp_core->class)`导致class被销毁，但`g_disp_feature`仍然指向class，导致内存访问异常。 4. **第三个问题点**：`mi_disp_feature_init`函数中，kfree(df)后没有将df和g_disp_feature置为NULL，可能导致内存访问异常。 **问题总结**： * 死机原因是class的状态被销毁后没有同步给g_disp_feature。 * 需要将g_disp_core和g_disp_feature都置为NULL，并修复display初始化流程。 **建议**： * 修复display初始化流程，确保走正常流程。 * 在`mi_disp_core_deinit`函数中，将g_disp_core和g_disp_feature都置为NULL。 * 检查其他地方是否有类似的内存访问问题。 希望以上信息对您有所帮助！

[Android稳定性] 第039篇 [问题篇] 记几次判断为DDR不稳定导致的死机问题 4月前查看 评论
[Android稳定性] 第039篇 [问题篇] 记几次判断为DDR不稳定导致的死机问题

本文记录了工厂老化测试中多台机器死机的情况，作者评估为DDR问题。文章详细描述了8个案例，并分析了判定为DDR问题的依据，包括内核执行异常、空指针解引用、地址大小错误等。作者总结了DDR不稳定可能是原因，包括内存访问错误、多核系统的并发性、内存映射与虚拟内存、缓存一致性问题等。最后，作者建议对出问题的机器进行DDR压力测试，以验证DDR是否为问题根源。