1.Background:

echo 1 > /dev/watchdog 和 echo c > /proc/sysrq-trigger。前者可以进入ramdump模式，后者无法进入ramdump模式，应该如何查看问题。

分析：首先需要分析这两个命令在kernel中会如何运行。可能还需要从TZ,kernel, userspace三方面进行分析。

2.echo 1 > /dev/watchdog 和 echo c > /proc/sysrq-trigger

先区别两种进入ramdump方法

2.1 echo c > /proc/sysrq-trigger

直接可以从sysrq_handle_crash函数，定位到入口函数。

https://elixir.bootlin.com/linux/v6.18/source/drivers/tty/sysrq.c#L149

最后进入到vpanic函数中，

https://elixir.bootlin.com/linux/v6.18/source/kernel/panic.c#L428

终端中可以定位到的日志

整个流程走下来，发现在这里可能会调用一些函数链，加了日志打印，终端日志可以显示，跟watchdog看上去好像没什么关系

这里无需设置panic_timeout，如果设置panic_timeout, 系统在这里识别后会直接重启，也不会进入ramdump

最后系统会无限挂在这里，但是按道理来说，如果有喂狗动作，系统卡住之后，没有人喂狗，系统会自动restart，在restart流程中，会根据设置，使得系统进入ramdump或者直接重启，但是没有，这里我们再看一下另一种可以触发ramdump的模式

2.2 echo 1 > /dev/watchdog

这个时候需要看一下如何进入ramdump，在这里我们先了解kernel中，watchdog的种类还是有不少的，这时可以用C++的知识来解释，watchdog是个父类/抽象基类，sbsa watchdog作为子类/派生类，继承父类的属性和方法，可以扩展/重写。增加了ARM架构的特性

打开 ——写入——关闭

2.2.1 open watchdog流程

分析一个来说明继承特性

https://elixir.bootlin.com/linux/v6.18/source/drivers/watchdog/watchdog_dev.c#L144

watchdog_open会调用

watchdog_start会调用

本质会调用已经注册的watchdog函数，然后跳到sbsa watchdog

类似于有些watchdog_dev_ops会调用已经注册的watchdog设备的函数

watchdog did not stop那条日志打印在

这里主要看一下if和else if 的代码，这两个部分都未被执行，看一下为什么

前者：设备仍然存活，所以 !1=0 后者: 设备只会在收到magic字符才会关闭，也就是V，测试后V是可以正常使得watchdog关闭的

所以能判断，设备在被open后一直没有被关掉，没人喂狗所以才会使得系统进入ramdump, 同样证明了kernel side, watchdog师妹问题的

2.2.2 watchdog_ping

这个就是喂狗流程，同样可以看到日志中并没有喂狗流程，只有在release等调用才会喂狗，所以判断可能没有喂狗

3.userspace watchdog

在发现是没有打开watchdog之后，check了一下默认安装watchdog的状态

实际上是running的，但是watchdog并不起作用，解释一下下面的进程，上面那个是内核自动携带的，下面那个是userspace watchdog

最后是发现user watchdog是需要添加修改，极简修改就是加上在/etc/watchdog.conf里加上

watchdog-device = /dev/watchdog

可以使得识别watchdog设备

主要看alive那一行，会识别到设备，默认不做任何修改的alive是none