On Sat, Jul 04, 2026 at 11:15:13AM -0600, Tom Rini wrote: > On Sat, Jul 04, 2026 at 06:59:08PM +0200, Heinrich Schuchardt wrote: > > Am 4. Juli 2026 18:17:07 MESZ schrieb Tom Rini <[email protected]>: > > >On Sat, Jul 04, 2026 at 05:21:25PM +0200, Carlo Caione wrote: > > >> > > >> > > >> > On 4 Jul 2026, at 16:32, Tom Rini <[email protected]> wrote: > > >> > > > >> > On Sat, Jul 04, 2026 at 03:52:29PM +0200, Carlo Caione wrote: > > >> > > > >> >> U-Boot can autonomously start a hardware watchdog > > >> >> (CONFIG_WATCHDOG_AUTOSTART, default y) and service it from its main > > >> >> loop, but the EFI boot path never stops it: efi_exit_boot_services() > > >> >> tears the devices down without calling wdt_stop_all(), and a watchdog > > >> >> driver without a .remove hook leaves the hardware ticking across the > > >> >> firmware-to-OS handoff. > > >> >> > > >> >> An EFI-booted OS that does not take over the SoC watchdog within the > > >> >> remaining timeout is reset mid-boot at a wall-clock-dependent point. > > >> >> > > >> >> The UEFI specification (v2.11, section 7.5 "Miscellaneous Boot > > >> >> Services", EFI_BOOT_SERVICES.SetWatchdogTimer()) is explicit about the > > >> >> one watchdog it allows across the handoff: > > >> >> > > >> >> "The watchdog timer is only used during boot services. On > > >> >> successful completion of EFI_BOOT_SERVICES.ExitBootServices() the > > >> >> watchdog timer is disabled." > > >> >> > > >> >> U-Boot's UEFI watchdog (an EFI timer event) complies by construction. > > >> >> A > > >> >> platform watchdog silently surviving the handoff defeats the purpose > > >> >> of > > >> >> that rule: the OS has no generic way to know it is running, let alone > > >> >> to > > >> >> service it. > > >> >> > > >> >> Stop all watchdog devices in efi_exit_boot_services(), before the > > >> >> device > > >> >> teardown. > > >> >> > > >> >> Signed-off-by: Carlo Caione <[email protected]> > > >> > > > >> > NAK. We have had this come up before, and in short, the UEFI > > >> > specification needs to be fixed here, as generally speaking a watchdog > > >> > should never be stopped, as that leaves a gap where the system can hang > > >> > and thus defeat the point of having enabled a watchdog. > > >> > > >> > > >> Fair enough. > > >> > > >> For the record, the failure that motivated this: a pristine Ubuntu 26.04 > > >> arm64 image on a MediaTek Genio 700 EVK dies silently about 60 seconds > > >> after ExitBootServices(), 100% reproducible, at a wall-clock dependent > > >> point. The generic kernel ships the watchdog driver as a module, so > > >> nothing services the watchdog in time, and nothing tells the OS that it > > >> is running. From the user's side this is indistinguishable from broken > > >> firmware. > > >> > > >> In the meantime, is the accepted pattern hooking up a wdt_stop_all() in > > >> the EFI path via board_quiesce_devices()? That keeps the watchdog armed > > >> for the whole firmware lifetime and makes the handoff behaviour the > > >> board maintainer's call. > > > > > >No, Ubuntu needs to fix their kernel image to have the watchdog > > >available early. I hate to be difficult on this, but it's been a known > > >issue for years at this point that the spec needs to be updated. The > > >workaround here is for the watchdog to not be started until the OS is > > >ready to maintain it. > > > > > > > Best open a Launchpad bug explaining why this watchdog driver needs to be > > built in and not a module. > > I'll leave that to Carlos, and I would suggest digging out the mailing
... to Carlo, my apologies. -- Tom
signature.asc
Description: PGP signature
