Hi Jan, On Thu, 2024-06-27 at 11:26 +0200, 'Jan Kiszka' via EFI Boot Guard wrote: > On 26.06.24 23:35, Christopher Obbard wrote: > > Hi Jan, > > > > On Mon, 2024-06-24 at 10:07 +0200, 'Jan Kiszka' via EFI Boot Guard wrote: > > > On 18.06.24 13:57, Jan Kiszka wrote: > > > > 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? > > > > > > > > > > Second ping. Given all the fixes in master, I would like to release this > > > week. > > > > I managed to test efibootguard's iTCO V6 driver again with latest next > > branch > > and have not yet found the root cause. > > > > The same symptoms happen on two separate chipsets; > > - Kontron COMe-mEL10 (E2) SOM containing Elkhart Lake chipset. > > - Dell OptiPlex 7000 containing Alder Lake-S chipset. > > - Dell OptiPlex E4 containing Alder Lake-S chipset. > > > > I've tested two cases: > > - Setting efibootguard boot delay set to 60s, with watchdog set to 30s. > > - Setting efibootguard boot delay set to 5s, with watchdog set to 30s. > > > > Both cases end up with the watchdog timer not resetting. > > > > I then started the watchdog in Linux, and the watchdog doesn't reset there > > either! > > OK, then this might be a topic for the respective vendors.
For my testing, I've been using linux 6.6.32 with CONFIG_WDAT_WDT disabled. I have checked the NO_REBOOT flag in efibootguard (both before and after it is cleared), the bit is originally set to 0 which means that the hardware strap is not high (TCO1_CNT_REG reads as 0x1800 on both devices). I'll continue poking at this, in the meantime is there any chance you could test iTCO v6 on your side to see if there is any regression ? > > > > Everything above seems to work fine in qemu (and the Intel Braswell box). > > Any > > hints on what to try next ? > > Check that there is no WDAT description (or related BIOS option) on > these boards. That would take precedence if Linux has the feature > enabled - does it? Yeah - I checked that WDAT is disabled. Thanks, Chris -- 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/15b396c01038ec101fb0d27bbe3595edf4558ee4.camel%40collabora.com.
