On 10.06.24 23:48, 'Christopher Obbard' via EFI Boot Guard wrote: > Hi Jan, > > On Mon, 2024-06-10 at 23:37 +0200, Jan Kiszka wrote: >> On 10.06.24 20:14, 'Christopher Obbard' via EFI Boot Guard wrote: >>> Hi, >>> >>> I have been doing some testing with efibootguard, it seems like >>> efibootguard >>> fails to enable the watchdog on some of my hardware. I am testing this >>> with a >>> recent Linux build with all kernel watchdog drivers not built and the >>> efibootguard watchdog configuration option set to 30s. >>> >>> For this test, I expect the system to reboot roughly 30s after >>> efibootguard >>> initialises. >>> >>> Test results from a few machines I have to hand are as follows: >>> >>> - qemu x86_64 machine q35 (iTCO v2; wdt resets fine) >>> >>> - generic mini pc (iTCO v4, Braswell; wdt resets fine) >>> >> >> Err, we do not support iTCO v4 yet, see the related driver. Do you have >> patches on top? > > Sorry - I meant - generic mini pc (iTCO v3, Braswell; wdt resets fine) > > I have some WIP patch from the mailing list to enable iTCO v4 but it doesn't > seem to work correctly, I will respond to the previous thread NACKing it. > > >>> >>> >>> And some machines which do not seem to reset after the wdt has been >>> primed: >>> >>> - Atari VCS (I believe this machine contains an amdfch_wdt, but I didn't >>> verify that as yet; wdt does not reset) >>> >>> - Dell OptiPlex 7000 series mini PC (iTCO v6, Alder Lake-S; wdt does not >>> reset) I also have some other hardware which uses iTCO v6 which also do >>> not >>> seem to reset. >>> >> >> There might be an issue with clearing the no-reboot flag on the >> particular device. As its name says, that flag prevent any actual reboot >> if the timer expires. You should cross-check if Linux works fine and >> then dig deeper what exactly that driver does to ensure this. > > Thanks, I will test Linux as a next step and report back. > > >>> >>> >>> Do you have any recommendations on how to debug/fix these issues? It'd be >>> great to get this fixed before the next efibootguard release. If someone >>> can >>> also verify my claims, it'd be great. >>> >>> >>> ftr: I also think it'd probably make sense to redo my testing above, with >>> an >>> UEFI shell as a target, just in case some watchdog driver really was >>> feeding >>> the hardware. >>> >> >> BTW, you should be able to simulate a handing kernel fairly easily now >> by setting --with-boot-delay during configure to a value above the >> configured EBG timeout. > > That's a useful suggestion, keeping everything self-contained. >
Any news on this? Jan -- Siemens AG, Technology Linux Expert Center -- 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 efibootguard-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/6eab9071-07b7-4035-9fe4-b22f659ae7f9%40siemens.com.
