有关watchdog的个人学习

1. 对于watchdog的三个描述：pet，bark，bite

pet：喂狗，是一个定时循环的行为，一般<10s

bark：在设定的时间内没有喂狗，触发bark;bark是一个irq信号

bite：bark后仍然没有被喂，超出设定时间后触发bite;bite是一个FIQ信号

8450/8475之后，TME负责喂system watchdog（区别于之前的TZ喂狗）; 与此同时，新增一个watchdog在app cpu subsystem上。触发这个watchdog时，它的bite信号会发给TME，TME保存数据并reset系统。

默认情况下bark和bite和pet时间使用default值，对nonsecure watchdog而言，默认bark时间为11s，bite时间为12s（指距离上一次喂狗时间）。

触发bark的原因大多数情况下都是禁用抢占权限、其他进程占用时间太多或log重复打印以及死锁现象。在高通文档中，有说明一些相关的config，如:

CONDIG_DEBUG_SPINLOCK,

CONFIG_DEBUG_MUTEXES,

CONFIG_DEBUG_ATOMIC_SLEEP

2. Watchdog for APPS CPU

这是大多数时候我们处理的watchdog问题。

2.1 non secure HW watchdog [NS watchdog]

原理是在HLOS上设置一个定时器，定期喂non-secure watchdog HW;11s内不喂狗触发bark。HLOS可以处理，则自行进panic;不能处理则交由TZ处理。

NS watchdog，每个CPU负责对自己的watchdog进行操作。

2.2 secure watchdog

secure watchdog每6s发送一次bark到TZ作为FIQ，FIQ处理器接受到信号后喂secure watchdog HW;TZ在22s后未能处理bark信号，则触发bite，并将中断信号传递给USC。

2.3 system watchdog

2.4 android software watchdog

运行在虚拟机上的watchdog java线程，路径为framworks/base/services/java/com/android/server/watchdog.java.通常情况下watchdog周期为60s，debug模式下设置为10s.

原理：watchdog定时向处理器发送监视信号;检测到挂起后，watchdog保存现场并杀死system进程从而引发重启。这不是一个严格的系统崩溃，而是内核可以恢复的错误。

通过查看保存了线程和进程情况的trace logs可以定位死锁情况。

3. log查看

3.1 触发了kernel panic

non secure watch dog bark:

        watchdog bark!now = .....

        watchdog last pet at ......

        CPU alive mask from last pet 0-3

        kernel panic - not syncing: Apps watchdog Bark received!

3.2 不是由panic引起的watchdog bite

       由一些意外的堵塞引起了pet的堵塞。

4. 标志性log和可能的成因

        4.1 log过多堵塞

                出现大量log的重复输出，如每100行就出现的log等

        4.2 明显的特殊驱动

        例如在stack结束前出现了spinlock或mutex call，可能是产生了死锁;

        4.3 调度问题

        在dmesg_TZ中若出现了许多pending workqueue内容和几条workqueue busy内容，这些内容中的一个可能堵塞了workqueue，可以用grep追查可能长时间占用的部分。

        检查irq和runqueue，以确认是否是由于irq过多或RTtask堵塞了CPU。若当前正在运行的进程是swapper，则另有说明。此外，要注意有没有RT Throttling的部分，出现这份log的原因可能是堵塞而导致的watchdog无响应。

        4.4 定时器本身问题

        4.4.1 计时器bug

        检查timelist.txt，比对计时器列表和计时器

        4.4.2 内存损坏导致计时器问题

        timerlist中出现了一些异常随机的数据，说明可能是内存问题

        4.4.3 硬件层损伤导致的计时器异常