我要搞死看门狗（第一季）

HW reboot原因

    WDT第1阶段超时将触发FIQ，如果CPU没有响应或CPU响应了但没有在第2阶段超时时间内完成重启，就好导致第2阶段超时发出复位信号复位整个系统，生成的db类型就是HW reboot。

    可以看到HW reboot定义很简单，这样导致了许多问题都导向了HW reboot，而处理问题的方法都不一样。那有哪些异常会导致HW reboot？有如下：

HW reboot调试信息

    基于HW reboot产生原因的复杂性。我们要学会如何区分呢？首先我们要了解哪些信息可以给我们参考。HW reboot没走任何软件流程，是直接复位的，无法知道CPU处于什么状态，因为重启后什么都丢了，不像kernel panic或HWT有详尽的CPU寄存器和调用栈参考。其实HW reboot还是有些硬件模块记录了当时的情况。

wdt status/fiq step

    在preloader初始化WDT前保留了WDT_STA寄存器的值，并转化为wdt status（或者叫hw_status），这个值保存在SYS_REBOOT_REASON/SYS_LAST_KMSG/__exp_main.txt，和fiq step一起。详情可参考：[FAQ14332]SYS_LAST_KMSG里的hw_status和fiq step的含义。

    wdt status提供了重启的原因，1或5是HW reboot，2是SW reboot等。fiq step的值为0或非0提供了是否走了kernel panic或HWT的流程。如果fiq step不为0，即使wdt status为1或5，我们都不会当成HW reboot来分析。这种情况的原因是panic或HWT流程卡住导致HW reboot了，我们需要参考last kmsg，按普通的kernel panic或HWT分析，找问题的原因。

    如果wdt status为1或5且fiq step为0，那么这个就是HW reboot了。如何调试呢？好像这些信息无法帮我们找到问题。我们继续看还有哪些调试信息。

last pc

    从82/92及之后的平台，WDT发出复位信号的同时锁存了online CPU的PC/FP/SP。在重启后记录在db的SYS_REBOOT_REASON里，格式如下：

    有些平台有特别的设定，比如MT6795的PC值有特别的含义：

• 0xa0a0a0a0a0a0a0a0：PC为空，表示没抓到last PC。
• 0xb0b0b0b0b0b0b0b0：抓取last PC失败。

    还有PC所指地址代表的含义大家也要清楚才行，以前平台的AP是扁平结构，PC值所在位置要吗在user space：0～0xBF000000，要吗在kernel space：0xBF000000～0xFFFFFFFF，后面引入64位使问题变复杂了。在aarch64下，PC值可能值NS EL0 user space，也可以是NS EL1 kernel space，或者SEC EL3 ATF及SEC EL1 TEE OS的。因此就需要了解整个框架，才能进一步判断PC来自于哪一层了：

• 64bit kernel space：0xFFFFFF8000000000~0xFFFFFFFFFFFFFFFF。其中0xFFFFFFC000080000开始就是kernel代码起始地址。
• 64bit user space：0～0x7fffffffff，所有app都跑在这里。
• ATF space：不同平台有不同的layout。
  • MT6752/MT6580/MT6795/MT6797的ATF代码段位于0x111000-0x12C400
  • MT6735/MT6753/MT6735M位于0x43001000-0x43020000
  • MT6755位于0x101000-0x120000

    通过last PC可以知道在最后时刻，各个CPU都在干什么。一般会检查PC所在函数：

• 是否是个死循环。看之前是否关闭了FIQ，如果是，则需要检查代码。
• 正在读写寄存器。读写已关闭clock/power的模块的寄存器会引起bus hang，引起HW reboot。这时要检查读写了哪个模块的寄存器，如果是chip内部模块，直接找Mediatek分析。
• 不在任何space里。那可能跑飞了，多半是HW不稳定引起。需要测量CPU vproc/vsram/Vm等重要电压，看异常发生前是否发生过drop等异常现象。
• 在正常函数里。但没有死循环或其他可疑的地方，这种也可能是HW不稳定，和上面的case一样测量重要电压。

system tracker

    上面有提到，如果是读写了已关闭clock/power的寄存器会引起bus hang，最后HW reboot。如何调试这种情况呢？在MT6595及之后引入了system tracker，这个硬件模块会监控bus情况，如果卡死会送一个abort信号给CPU，CPU会进入kernel panic流程。但有时这个bus hang会引起CPU bus卡死，导致CPU也动不了而变成HW reboot。不过bus hang信息还保留在system tracker模块中，重启后会被打包到HW reboot db里。

    如果db里存在SYSTRACKER_DUMP文件，那一定是发生过bus hang了，该文件内容如下：

    上面记录的地址是物理地址，需要查找datasheet看是哪个模块的寄存器。然后检查代码，看看last pc所在函数是否有可能当时的power/clock被关闭了。

Low-Power功能标记

    在SYS_REBOOT_REASON不只有wdt status、fiq step和last pc，还有一堆如下内容的信息：

    这些信息显示了系统当时的状态，比如是否进入sodi，当时dvfs档位状态等等。因为系统的复杂性，这些信息也算是提供一些参考吧。

CPU hot plug

    还有一个重要的信息就是hot plug信息，每个CPU都有，不过CPU0比较特殊，因为不会发生hot plug（在新平台上，CPU0也会发生hot plug），因此有3个参数，其他CPU都只有1个参数：

    CPU0的的参数含义如下：

CPU事件定义在kernel-3.10/include/linux/cpu.h里（2表示CPU_ONLINE）：

#define CPU_ONLINE 0x0002 /* CPU (unsigned)v is up */
#define CPU_UP_PREPARE 0x0003 /* CPU (unsigned)v coming up */
#define CPU_UP_CANCELED 0x0004 /* CPU (unsigned)v NOT coming up */
#define CPU_DOWN_PREPARE 0x0005 /* CPU (unsigned)v going down */
#define CPU_DOWN_FAILED 0x0006 /* CPU (unsigned)v NOT going down */
#define CPU_DEAD 0x0007 /* CPU (unsigned)v dead */
#define CPU_DYING 0x0008 /* CPU (unsigned)v not running any task, not handling interrupts, soon dead. Called on the dying cpu, interrupts are already disabled. Must not sleep, must not fail */
#define CPU_POST_DEAD 0x0009 /* CPU (unsigned)v dead, cpu_hotplug lock is dropped */
#define CPU_STARTING 0x000A /* CPU (unsigned)v soon running. Called on the new cpu, just before enabling interrupts. Must not sleep, must not fail */

    其他CPU参数含义如下（比如54表示CPU已经下电了）：

last kmsg

    最后的参考资料是last kmsg，看看是否存在异常。如果没有看到异常，就看最后log停在哪里。猜测和哪个模块相关，然后进一步调试。

分析方法

    有了以上的调试信息，我们就可以开始分析了。纯粹的HW reboot一般和HW相关性较大。结合以上信息还不足以定位，通常还需要更多信息，比如复现次数等，大致分析如下：

    仅1次复现，如果以上的调试信息看不出问题点就只能后面在关注是否再次发生了。

    可复现的话，需要关注复现路径，发生问题的时间点，结合多次复现的db统一分析，看是否有相似性。

    随机问题，基本导向HW故障，还需要进一步做信息调查：

    如果软件分析没有任何进展，则需做HW验证：

结语

    HW reboot是一个复杂的问题，需要积累经验及扩大知识面。还要积累各种调试手段，比如DVFS开关，hotplug开关等，这样调试起来才比较顺手。

案例分析