Ich benutze den 4.9 Linux-Kernel auf einer eingebetteten Plattform und bemerke, dass der Watchdog-Timer automatisch aktualisiert wird, obwohl ich keinen User-Space-Daemon wie die watchdog documentation erwähnt habe.Wer kickt den Watchdog-Timer in Linux lautlos?
Fast wörtlich genommen von shodanex's answer zu einer verwandten Frage.
Wenn Sie den Watchdog-Treiber in Ihrem Kernel aktiviert haben, richtet der Watchdog-Treiber einen Kernel-Timer ein, der den Watchdog zurücksetzt.
Wenn keine Anwendung die Datei/dev/watchdog öffnet, sorgt der Kernel dafür, dass der Watchdog zurückgesetzt wird. Da es sich um einen Timer handelt, wird er nicht als dedizierter Kernel-Thread angezeigt, sondern vom weichen IRQ-Thread. Wenn nun eine Anwendung diese Datei öffnet, wird sie für den Watchdog verantwortlich und kann sie zurücksetzen, indem sie in die Datei schreibt, wie dokumentiert the watchdog documentation.
Im Juli 2016 hat a commit in the 4.7 kernel Watchdog_dev.c dieses Verhalten für alle Watchdog-Timer-Treiber aktiviert. Vor dieser Zeit scheint es pickelig und fahrerspezifisch zu sein. Das Verhalten scheint nirgendwo anders als in diesem Thread und dem Quellcode dokumentiert zu sein.
/*
* A worker to generate heartbeat requests is needed if all of the
* following conditions are true.
* - Userspace activated the watchdog.
* - The driver provided a value for the maximum hardware timeout, and
* thus is aware that the framework supports generating heartbeat
* requests.
* - Userspace requests a longer timeout than the hardware can handle.
*
* Alternatively, if userspace has not opened the watchdog
* device, we take care of feeding the watchdog if it is
* running.
*/
return (hm && watchdog_active(wdd) && t > hm) ||
(t && !watchdog_active(wdd) && watchdog_hw_running(wdd));