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. > > 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? > > I don't think this should block the release, since Linux also seems to suffer > from the same issue. > Ack, I will move forward now. Thanks, 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/2af7c79a-3980-40e3-8369-ff21ceeebae0%40siemens.com.
