林渡 - 云栖梦泽

[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。 * 检查其他地方是否有类似的内存访问问题。希望以上信息对您有所帮助！

MTK平台模块加载顺序控制

本文主要探讨了Android设备中模块加载顺序控制的相关知识点。首先，介绍了模块在文件系统中的位置要求，包括不同启动模式下模块的存放位置和加载顺序。接着，阐述了Android构建系统如何通过定义变量来支持模块加载，并举例说明了供应商内核模块的配置方式。然后，针对MTK平台，详细分析了模块加载控制机制，包括`ko_order_table.csv`文件的作用、编译逻辑以及树外驱动编译控制。最后，总结了设置模块加载顺序的原则，即通过调整`ko_order_table.csv`中的顺序来控制模块加载顺序，遵循先加载ramdisk模块，后加载vendor模块，且同一类型模块中，顺序靠前的先加载。

[Android稳定性] 第039篇 [问题篇] 记几次判断为DDR不稳定导致的死机问题

[智谱AI 摘要生成异常：Server returned HTTP response code: 429 for URL: https://open.bigmodel.cn/api/paas/v4/chat/completions | {"error":{"code":"1113","message":"余额不足或无可用资源包,请充值。"}}]

[Android稳定性] 第040篇 [问题篇] 高通平台tz busy造成的卡死问题

**问题摘要：** 近期，工厂和开发版本中出现大量死机问题，原因指向tz相关的`qcom_scm_pas_auth_and_reset`函数异常。日志显示tz处于忙碌状态，且`mfido`固件更新可能为根本原因。 **问题分析：** 问题源于`qcom_scm_pas_auth_and_reset`函数返回异常，导致系统panic。日志分析发现tz处于忙碌状态，且`mfido`固件更新可能与问题相关。进一步分析显示，`mfido`在尝试读取公钥证书时失败，引发系统崩溃。 **根本原因：** 安全团队提交的`mfido`固件更新可能是导致死机的根本原因。更新后的固件在初始化过程中出现错误，导致tz无法正常响应，进而引发系统崩溃。

[Android稳定性] 第038篇 [问题篇] 在workqueue中取消自身导致的workqueue自锁

在高低温测试后出现工模卡死问题，通过手动组合键获取dump和日志分析发现，卡死主要涉及g_reclaim_threa、kworker和电池相关进程，均处于不可中断状态，线程堆栈显示重复调度和互斥锁等待。问题集中在充电管理和电池状态处理流程，表明驱动在极端温度下存在逻辑漏洞。

[Android稳定性] 第033篇 [问题篇] suspend时shedule io操作导致线程阻塞引发死机

## 一、问题背景工厂BLMMI工站的一台机器出现死机，进入dump状态。 ## 二、问题分析 ### 2.1 初步定位通过分析dmesg日志，确定死机原因为watchdog bite，CPU0发生。 ### 2.2 定位卡死线程分析日志发现系统在挂起后未能正确resume，导致watchdog未在20秒内被喂狗。 ### 2.3 查找阻塞的进程通过查看tasks.txt，发现irq/141-pmic_pw线程卡在不可中断睡眠状态，推测为卡住的线程。 ## 三、根本原因分析分析栈回溯，发现irq/141-pmic_pw线程在挂起阶段执行mtdoops dump操作时，底层block device已挂起，导致线程卡死，无法完成resume。 ## 四、解决方案 1. 在pwrkey_long_press_irq_event中仅设置标志，延迟执行dump操作。 2. 在系统resume后通过workqueue异步触发dump。 ## 五、效果避免挂起阶段执行阻塞的dump操作，解决suspend卡死问题。 ## 六、测试建议 1. 检查按电源键时是否出现defer dump日志。 2. 检查挂起后唤醒是否出现Executing deferred mtdoops dump after resume日志。 3. 观察是否还会触发watchdog bite。

[Android稳定性] 第036篇 [原理篇] 理解中断上下文、进程上下文以及进程调度之间的关系

本文深入探讨了进程上下文、中断上下文以及 Linux 进程调度器（如 CFS）的概念和关联性。进程上下文是内核代码为特定进程执行任务的环境，能被调度、休眠和参与 CFS 调度。中断上下文是内核响应中断时运行的代码环境，不能睡眠，且不直接参与调度。SoftIRQ 和 Tasklet 作为中间层，处理中断后的任务。三者之间的关联性体现在中断上下文可以触发调度事件，而进程上下文可以主动调用调度器。文中还列举了在中断上下文中不能调用的函数或行为，并强调了中断上下文中禁止使用可能引起睡眠或阻塞的函数，以避免系统问题。

你好,

我是林渡