On Tue, 15 Sep 2020, 7:54 PM Michael Walle, michael@walle.cc wrote:
Am 2020-09-15 09:44, schrieb Rayagonda Kokatanur:
On Tue, Sep 15, 2020 at 12:56 PM Michael Walle michael@walle.cc wrote:
Hi Stefan,
it appears that since commit 06985289d45 ("watchdog: Implement generic watchdog_reset() version") - by default - the first watchdog is started unconditionally if CONFIG_WDT is set but never stopped before booting the operating system.
Shouldn't it also be stopped uncondionally? What's worse is that on one board/arch the watchdog is stopped in arch_preboot_os() which is never called in the bootefi case. So even if I'd do a workaround and stop it manually in my board code, I couldn't do that consistently for bootm/bootefi.
Or am I missing something here?
Define CONFIG_WATCHDOG. This takes care of resetting wdt.
Yes as along as you're inside the bootloader, but when u-boot hands control over the OS the watchdog is not serviced anymore; which wouldn't be a problem per se, but it is enabled unconditionally by u-boot.
Just to add some data. At $dayjob we use this behaviour as a failsafe to make sure our userspace gets to a point where it is servicing the watchdog. That said having a leave-wdt-running environment variable would work for our use case.