避免MTK设备死机重启：手把手教你调试hang_detect和watchdog问题

深入MTK平台系统稳定性：从机制到实战，全面解析hang_detect与看门狗调试

在嵌入式设备，特别是基于MTK平台的智能终端开发中，系统稳定性是衡量产品质量的核心指标之一。开发者们常常会遇到设备在特定场景下无预警重启的问题，日志中频繁出现的“hang_detect”和“watchdog timeout”字样，往往意味着系统陷入了某种僵局。这类问题排查起来犹如大海捞针，不仅需要深入理解内核机制，更考验工程师的系统性调试思维。本文旨在为嵌入式开发者和技术支持人员，提供一套从原理到实战的完整调试框架，帮助大家精准定位并解决由系统挂起检测机制引发的重启难题，从而打造出更稳定可靠的产品。

1. 理解MTK平台的守护者：看门狗与挂起检测机制

要解决问题，首先得理解问题背后的“裁判”。在MTK平台，系统稳定性的守护主要由两套机制协同完成：硬件看门狗（Watchdog Timer, WDT）和软件层的挂起检测（hang_detect）。它们的关系，可以比作一个双重保险系统。

硬件看门狗是一个独立的计时器电路。其核心逻辑非常简单：系统需要在规定的时间间隔内（例如30秒）定期“喂狗”（即向特定寄存器写入一个值），以重置计时器。如果系统因为死循环、死锁或调度异常等原因卡住，无法按时执行喂狗操作，看门狗计时器就会溢出，触发一个不可屏蔽的中断（NMI）或直接引发硬件复位，强制系统重启。这是一种硬件级别的“终极恢复”手段。

而hang_detect机制则是MTK在软件层面，特别是内核驱动中实现的一种更精细化的健康检查。它本质上是一个内核线程，会周期性地检查关键用户空间进程（如system_server、surfaceflinger）以及内核自身关键路径的运行状态。它的工作逻辑比单纯的计时更智能：

1. 状态监控：hang_detect线程会监控目标进程是否还能响应心跳，或者关键的内核锁、信号量是否在合理时间内被释放。
2. 分级响应：当检测到疑似挂起时，它并非立即重启，而是进入一个“宽限期”。在这个宽限期内，系统会尝试收集诊断信息，如打印所有CPU的堆栈回溯（backtrace）、记录进程状态等，生成AEE（Android Exception Engine）异常数据库（DB），为后续分析留下宝贵线索。
3. 最终裁决：如果宽限期结束后系统仍无响应，hang_detect机制才会最终触发看门狗复位。

注意：system_server进程每30秒对看门狗驱动节点的“kick”操作，是连接用户空间与内核看门狗的关键纽带。这个环节出问题，会直接导致硬件看门狗超时。

理解这两者的关系至关重要：hang_detect是“诊断医生”，而硬件看门狗是“急救按钮”。很多时候，我们看到的重启是由hang_detect这个“医生”在经过诊断后，主动按下了“急救按钮”。

1.1 解读重启倒计时：count值的秘密语言

在分析/proc/last_kmsg或AEE DB中的日志时，你会频繁看到一个名为count的变量。这个值并非随意出现，它是hang_detect线程内部的一个倒计时器，其数值变化精确对应了系统从异常发生到最终重启所经历的不同阶段。解读这些count值，是判断问题类型和发生时间点的第一把钥匙。

下面这个表格梳理了不同count值对应的典型场景和系统状态：