有关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 硬件层损伤导致的计时器异常