2025 年 4 月 15篇

[Android稳定性] 第040篇 [问题篇] 高通平台tz busy造成的卡死问题 7月前查看 评论
[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自锁 7月前查看 评论
[Android稳定性] 第038篇 [问题篇] 在workqueue中取消自身导致的workqueue自锁

### 一、问题背景 在441#-AS1-KKX_0411版本高低温运行测试后，出现工模卡死现象，需手动组合键进入dump。日志分析显示，卡死时刻多个线程处于D状态，包括batterysecret、charge_logger、xm_charge_work和fsa4480_usbc_analog_work_fn等。这些线程都在等待同一个IIO mutex，导致锁争用。 ### 二、根本原因 reverse_charge_monitor_workfunc函数在执行过程中，调用了iio_write_channel_raw函数，该函数持有iio_dev的mlock锁。随后，该函数又调用了smblib_handle_reverse_charge_event函数，该函数中包含cancel_delayed_work_sync(&self)操作，导致当前work无法退出，陷入死锁状态。 ### 三、解决方案 1. 修改reverse_charge_monitor_workfunc函数，将smblib_handle_reverse_charge_event函数的调用移至mutex_unlock(iio_dev->mlock)之后。 2. 考虑使用其他同步机制，如信号量或事件，避免锁争用。 ### 四、总结 通过分析日志和追踪源码，发现卡死现象是由reverse_charge_monitor_workfunc函数中的死锁导致的。通过修改函数调用顺序和使用其他同步机制，可以解决此问题。

[Android稳定性] 第033篇 [问题篇] suspend时shedule io操作导致线程阻塞引发死机 7月前查看 1 条
[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篇 [原理篇] 理解中断上下文、进程上下文以及进程调度之间的关系 7月前查看 评论
[Android稳定性] 第036篇 [原理篇] 理解中断上下文、进程上下文以及进程调度之间的关系

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

[Android稳定性] 第037篇 [问题篇] vote函数持锁造成经典的AB-BA死锁 7月前查看 评论
[Android稳定性] 第037篇 [问题篇] vote函数持锁造成经典的AB-BA死锁

您好，我是一位专业的100字左右文章摘要总结写手。根据您提供的问题背景和日志分析，本文将探讨一个在Android设备老化测试过程中遇到的问题。具体来说，当使用组合键手动进入dump状态时，设备卡在了某些进程上，无法继续执行。通过分析dmesg日志，我们发现多个进程处于D状态，且存在锁的竞争关系。最终，我们确定这是一个典型的AB-BA锁死锁问题。

【深入内核】Linux 内核栈初步了解 7月前查看 评论
【深入内核】Linux 内核栈初步了解

这篇文章详细介绍了Linux内核栈的概念、重要性以及与之相关的常见问题和调试方法。内核栈是Linux为每个线程在运行内核代码时专用的一块栈空间，用于保存函数调用链、局部变量、寄存器上下文等信息。文章强调了内核栈的大小固定（在ARM64架构下默认为16KB），不可扩展，并指出了在栈上分配大数组、返回栈上变量地址等常见“死亡操作”。此外，还提供了如何调试内核栈使用的方法，包括编译选项、工具和查看系统文件。最后，总结了避免内核栈溢出的建议，以确保系统稳定运行。

[Android稳定性] 第035篇 [问题篇] 中断风暴触发watchdog bite 7月前查看 评论
[Android稳定性] 第035篇 [问题篇] 中断风暴触发watchdog bite

**问题背景**：系统出现死机现象，且插上屏幕后问题消失。 **问题分析**： 1. **dmesg分析**：发现watchdog被触发，导致系统死机。 2. **堆栈分析**：`dsi_ctrl_hw_cmn_ctrl_reset()`函数卡住，没有正常返回。 3. **中断分析**：系统处于中断风暴状态，`msm_drm`和`dsi_ctrl`模块中断触发频率异常高。 4. **中断号分析**：通过T32工具查找中断号，进一步确定问题根源。 **根本原因**： 某个设备中断（如QtiBus/IPC/CAN）在IRQ handler中未及时退出，导致CPU被中断处理任务占满，无法进行正常调度，最终触发watchdog并导致死机。

[Android稳定性] 第034篇 [问题篇] 进程阻塞触发watchdog bite死机 7月前查看 评论
[Android稳定性] 第034篇 [问题篇] 进程阻塞触发watchdog bite死机

## 问题摘要： 本次老化测试中，设备出现死机问题，经过日志分析，初步判断为 **CPU0 调度器 hang 死** 导致。具体表现为： * **CPU0 定时器更新滞后**：与其他 CPU 相比，CPU0 的定时器 `timer_jiffies` 落后约 20 秒，且大量定时器处于停滞状态，说明 CPU0 的定时器中断处理函数可能未正常执行。 * **高精度定时器未触发**：CPU0 的 `tick_sched_timer` 等高精度定时器 `_softexpires` 值停滞，说明 CPU0 的定时器中断机制未运作，导致系统调度器无法运行，看门狗无法被喂，CPU 卡死。 * **任务调度异常**：大量内核后台任务 `kworker/0:*` 卡在不可中断的 `D` 状态，`ksoftirqd/0` 停止调度，说明内核资源可能无法释放，调度器已崩溃。 * **CPU0 栈分析**：`QtiBus-PROC` 独占 CPU0 运行权，其他任务无法调度，且其调用栈显示卡在 `do_exit` 函数，说明该线程在退出过程中卡死，导致 CPU0 调度器 hang 死。 ## 根本原因： `QtiBus-PROC` 线程在退出过程中卡在了 futex 和 RCU 回调相关路径，导致它阻塞在 CPU0 上不让出 CPU，最终让整个 CPU0 的调度器 hang 死，系统无法喂 watchdog，被重启。

[Android稳定性] 第032篇 [原理篇] 高通平台 OCP & 组合键 Warm Reset 机制详解 8月前查看 评论
[Android稳定性] 第032篇 [原理篇] 高通平台 OCP & 组合键 Warm Reset 机制详解

本文深入探讨了Qualcomm平台Android系统中两种底层重启方式：OCP（过电流保护）触发的Warm Reset和通过组合键+Timer配置触发的Warm Reset。OCP是一种硬件保护机制，能监测供电轨是否过电流并执行Warm Reset。该重启不经过软件，重启后无last_kmsg记录。组合键+Timer配置则通过PMIC硬件监控按键状态，独立于软件，配置在Android启动后仍生效。两种重启方式均适合用于调试。

[Android稳定性] 第031篇 [原理篇] Linux内核内存检测工具KASAN 8月前查看 评论
[Android稳定性] 第031篇 [原理篇] Linux内核内存检测工具KASAN

Kasan（Kernel Address Sanitizer）是一个动态检测内存错误的工具，主要功能是检查内存越界访问和使用已释放的内存等问题。Kasan集成在Linux内核中，随Linux内核代码一起发布，并由内核社区维护和发展。在Android内核开发中，Android包括内核地址排错程序(KASan)。KASan是内核与编译时修改的组合，形成了一个插桩系统，可以实现更简单的bug发现和根本原因分析。KASan可以检测内核中许多类型的内存违规行为，包括堆栈、堆和全局变量中的出界读取和写入操作，并可检测释放后再使用和双重释放错误。

[Android稳定性] 第030篇 [问题篇] I2C bus hang 导致锁线程阻塞导致卡死 8月前查看 评论
[Android稳定性] 第030篇 [问题篇] I2C bus hang 导致锁线程阻塞导致卡死

本文分析了测试过程中出现的ANR问题，通过分析bugreport日志，发现大量内核线程卡在“不可中断睡眠”状态，表明线程正在等待I/O操作。进一步分析发现，问题可能出在电池/充电控制相关驱动上，因为涉及I²C通信和电源管理的模块出现异常。此外，fg_read_volt函数在I²C读失败后，会尝试重试，但可能因为互斥锁或I2C总线问题导致永久阻塞，进而引发系统内多个线程进入D状态。根本原因可能是I²C传输超时导致regmap_raw_read函数卡住或失败，进而导致fg_read_word和fg_read_volt函数卡住或多次失败，最终引发线程风暴。可能的原因包括硬件层面的I²C总线锁死、Fuel Gauge芯片异常、电池连接问题，以及软件层面的I²C驱动问题、多线程并发访问问题、I²C错误处理问题等。