Re: [PATCH v4] fix it87_wdt early reboot by reporting running timer

["René Rebe" <rene@exactco.de>]

> On 12. Dec 2025, at 23:41, James Hilliard <james.hilliard1@gmail.com> wrote:
> 
> On Fri, Dec 12, 2025 at 3:34 PM René Rebe <rene@exactco.de> wrote:
>> 
>>> On 12. Dec 2025, at 23:28, James Hilliard <james.hilliard1@gmail.com> wrote:
>>> 
>>> On Fri, Dec 12, 2025 at 3:16 PM René Rebe <rene@exactco.de> wrote:
>>>> 
>>>> 
>>>>> On 12. Dec 2025, at 23:04, James Hilliard <james.hilliard1@gmail.com> wrote:
>>>>> 
>>>>> On Fri, Dec 12, 2025 at 2:50 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>> 
>>>>>> On 12/12/25 12:17, James Hilliard wrote:
>>>>>> ...
>>>>>>>  +       /* wdt already left running by firmware? */
>>>>>>>  +       if (_wdt_running()) {
>>>>>>>  +               pr_info("Left running by firmware.\n");
>>>>>>> 
>>>>>>> 
>>>>>>> I'm wondering, is there a way other than looking at dmesg to identify if
>>>>>>> a wdt was left running by the firmware? I'm thinking having an ioctl or
>>>>>>> similar could be useful as a way to notify a user that a BIOS or firmware
>>>>>>> configuration change may be needed.
>>>>>>> 
>>>>>> 
>>>>>> This is not a bug, so there is no need to notify the user in the first place.
>>>>>> The only reason for accepting the message is that I was tired arguing.
>>>>>> It is even misleading, because loading the driver, starting the watchdog
>>>>>> by touching the watchdog device, unloading it, and loading it again will
>>>>>> likely trigger the message.
>>>>> 
>>>>> Yeah, I'm aware it's not a bug, I'm just thinking it might be good to have
>>>>> watchdog drivers record the initial running state.
>>>> 
>>>> The kernel logs so much pointless random stuff; an info about a
>>>> running watchdog timer is more than warranted in this case IMHO.
>>>> It wasted quite a bit of my valuable time.
>>>> 
>>>>>> Userspace can check if a watchdog is running by reading
>>>>>> /sys/class/watchdog/watchdog<index>/state. Do that after loading the driver
>>>>>> and before starting the watchdog daemon and you'll see if the watchdog
>>>>>> was running when the driver was loaded. But that doesn't mean it was
>>>>>> running when the system booted; it only means that the watchdog was running
>>>>>> when the driver was loaded.
>>>>> 
>>>>> Hmm, this seems impossible in some configurations, AFAIU systemd's
>>>>> watchdog is integrated into PID 1, so loading a watchdog daemon later
>>>>> doesn't appear possible.
>>>>> 
>>>>> Maybe it would make sense to have a sysfs variable like
>>>>> /sys/class/watchdog/watchdog<index>/initial_state so that
>>>>> there's a way for userspace to determine if a watchdog was
>>>>> already armed by the time the driver was loaded?
>>>> 
>>>> This would be quite wasteful overkill for something that unimportant.
>>>> It is rare that firmware leaves a watchdog timer enabled in any case.
>>> 
>>> I think your presumption that a watchdog is unimportant is wrong,
>>> in my case I want to identify systems and send alerts if it's detected
>>> that a watchdog was NOT armed by the firmware.
>>> 
>>> I manage a bunch of x86_64 based embedded systems and
>>> we always want the watchdog enabled, including in the BIOS,
>>> however unlike on your system the watchdogs on my systems are
>>> disabled by default and must be manually configured in the BIOS.
>>> We do still arm them from Linux either way but it would be nice
>>> to warn users that their systems have bad BIOS settings, on the
>>> systems I work with failing to arm the watchdog in both the BIOS
>>> and Linux can result in the watchdog failing to fire when we need
>>> it to under some circumstances(we're not sure exactly why this
>>> happens but failing to arm the watchdog in the BIOS can result
>>> in the watchdog not always firing if the system freezes during a
>>> reboot from what we can tell, although it's difficult to reproduce
>>> this issue in our hardware testing lab).
>> 
>> Instead of adding new kernel state, you could probably just read
>> the initial state as suggested by Guenter.
> 
> As I mentioned earlier, I don't think we can read initial state since
> AFAIU systemd PID1 will immediately arm the watchdog prior
> to anything else running, so by the time we could read the state
> variable the watchdog would have already been armed so the
> state var would be meaningless in regards to determining if the
> firmware armed the watchdog.

You can either adjust systemd accordingly or add a /sbin/init
wrapper for systemd to check the state before executing init.

With the added benefit of working with older kernels.

	René

-- 
https://exactco.de • https://t2linux.com • https://patreon.com/renerebe