On 01.11.21 14:40, François Dussault wrote: > I somewhat isolated the problem. I used efibg 0.9 and tested with an > infinite loop at the end of efi_main() just before loading the image, > and indeed in this case the watchdog does work. > Furthermore, when booting, I noticed that disabling the module (in my > case, it is built-in the kernel) with > initcall_blacklist=iTCO_wdt_init_module in the kernel options does fix > my issue (basically the watchdog does reboot the system a little while > after booting into linux as expected). > > So it seems the cause of my issues is that the iTCO_wdt module somewhat > resets the watchdog set by efibg at boot. I wonder if it's possible to > make the module load without messing with the efibg watchdog set at boot. >
This is what handle_boot_enabled is supposed to do: When disabled, the kernel driver will not take care of an already running watchdog until userspace picks up. It should just issue a message like "watchdog0 running and kernel based pre-userspace handler disabled" provided it detects the watchdog as running. Seems that is not the case for the iTCO driver (I see no set_bit(WDOG_HW_RUNNING, ...)). It might be that the kernel driver actually initializes the watchdog into a stopped state. That would be bad for our use case, indeed. Christian, you worked a lot with iTCO. Did you observe such a behavior with the Linux driver? > Second, I noticed in "bg_setenv -c" that the code for the "-c" argument > doesn't contain anything that stops the watchdog when confirming. I was > somewhat expecting this based on the state machine found in > "UPDATE.md" which seems to state the watchdog reboot doesn't happen if > we confirm in time. So even after confirming, my system will reboot > (even if iTCO_wdt did leave the efibg watchdog alone in an hypothetical > situation). > > One way I see of respecting UPDATE.md state machine (one way to make it > work) would be to compile the kernel with iTCO_wdt as a module and > preventing it to be loaded at boot. Then I could confirm with "modprobe > iTCO_wdt; bg_setenv -c" i.e. loading the module to cancel the watchdog > reboot, and then confirming > > But... isn't bg_setenv -c supposed to take care of the watchdog?! I'm > confused. > Nope, bg_setenv just flips the state in the EBG environment so that the next boot - no matter if caused by a watchdog or are regular reboot - does not cause to go back to the previous version. At the point bt_setenv -c is called, the kernel driver is supposed to manage the watchdog, EBG is only starting it and later on not in charge of it anymore. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/0f730ca7-ab2f-97b9-93b3-a9c0bbc890af%40siemens.com.
