![[Android稳定性] 第051篇 [原理篇] 从timer角度学习高通平台的watchdog](https://halo-19274848.oss-cn-shanghai.aliyuncs.com/2025/06/halo_4rxbkph.png?x-oss-process=image/resize,w_800,m_lfit)
[Android稳定性] 第051篇 [原理篇] 从timer角度学习高通平台的watchdog
本文主要介绍了Linux内核中的定时器机制,包括低精度定时器timer_list和高精度定时器hrtimer,以及它们在watchdog timer中的应用。文章首先介绍了timer_list的实现机制、核心数据结构和API,并通过一个简单的示例展示了其使用方法。接着,文章深入剖析了hrtimer的实现机制、核心数据结构和API,并给出了一个hrtimer定时器的示例驱动。随后,文章着重介绍了watchdog timer的使用,包括其初始化、喂狗线程函数和suspend/wakeup处理。此外,文章还介绍了基于软件的软看门狗机制,包括其基本原理、核心组件、检测流程和内核中的主要实现。最后,文章总结了watchdog timer的debug方法和技巧,并提供了一些常用的内核参数用于调试。
![[Android稳定性] 第049篇 [问题篇] 软中断霸占CPU导致watchdog无法及时喂狗](https://halo-19274848.oss-cn-shanghai.aliyuncs.com/2025/06/halo_tstlhyw.png?x-oss-process=image/resize,w_800,m_lfit)
[Android稳定性] 第049篇 [问题篇] 软中断霸占CPU导致watchdog无法及时喂狗
**问题现象**: 系统出现死机现象。 **问题分析**: 通过分析dmesg日志和内核定时器数据,发现是由于watchdog定时器未在规定时间内被“喂狗”导致。进一步分析发现,CPU 3上的定时器时钟落后,导致pet_timer无法在规定时间触发。 **问题根因**: 网络驱动中的软中断处理路径占用了较长时间的软中断上下文,并多次禁用底半部,导致定时器软中断无法及时执行。 **解决方案**: 建议优化网络驱动中的软中断处理路径,减少底半部的禁用时间,以确保定时器软中断能够及时执行。
![[Android稳定性] 第034篇 [问题篇] 进程阻塞触发watchdog bite死机](https://hexoimg.oss-cn-shanghai.aliyuncs.com/blog/25/4/cover_android_stability_034.png)
[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,被重启。