From: Michael Walle <michael@walle.cc>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: heinrich.schuchardt@canonical.com, u-boot@lists.denx.de,
agraf@csgraf.de, andre.przywara@arm.com, xypron.glpk@gmx.de
Subject: Re: [PATCH 1/1] efi_loader: stop watchdogs in ExitBootServices()
Date: Tue, 09 Nov 2021 15:54:27 +0100 [thread overview]
Message-ID: <ab55ce9823874154ef5b2d2dace38075@walle.cc> (raw)
In-Reply-To: <d3cac338f6650552@bloch.sibelius.xs4all.nl>
Am 2021-11-09 15:46, schrieb Mark Kettenis:
>> From: Michael Walle <michael@walle.cc>
>> Date: Tue, 9 Nov 2021 15:20:17 +0100
>>
>> > The UEFI specification requires for ExitBootServices() that "the boot
>> > services watchdog timer is disabled". We already disable the software
>> > watchdog. We should additionally disable the hardware watchdogs.
>>
>> What about watchdogs that cannot be stopped? IIRC the IMX SoCs are
>> like that.
>
> You have to hope that your OS takes control of the watchdog quickly
> enough for the machine not to reset in between. Strictly speaking
> such a platform can not be fully compliant with the UEFI standard. In
> practice this doesn't really matter as the OS has to do this quickly
> enough if you're using a non-UEFI bootpath anyway.
>
> Maybe somebody who cares enough can get the UEFI standard amended to
> handle this scenario. Maybe an interface can be added to the standard
> to provide more control over the watchdog such that the timeout can be
> set to a larger value before ExitBootServices() gets called. And add
> a way to keep the watchdog enabled on SoCs where it can be disabled.
> Last time this issue came up, someone pointed out that a watchdog that
> can be turned off isn't a proper watchdog. And indeed, turning the
> watchdog off when ExitBootServices() gets called means there is a time
> window where the watchdog isn't running and where the OS could hang
> forever.
Yeah there was already a disussion [1] about this very specific topic.
I just noticed there was another one this week.
Anyway, I was just wondering that is just _tries_ to disable it. Or
if you want to put it another way: the error is just ignored and the
user will then wonder why the board will do a reset (or not if
he's lucky).
-michael
[1]
https://lore.kernel.org/u-boot/20200923164527.26894-1-michael@walle.cc/
next prev parent reply other threads:[~2021-11-09 14:54 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-09 10:19 [PATCH 1/1] efi_loader: stop watchdogs in ExitBootServices() Heinrich Schuchardt
2021-11-09 10:19 ` Heinrich Schuchardt
2021-11-09 14:20 ` Michael Walle
2021-11-09 14:46 ` Mark Kettenis
2021-11-09 14:54 ` Michael Walle [this message]
2021-11-09 17:30 ` Heinrich Schuchardt
2021-11-09 17:55 ` Tom Rini
2021-11-09 18:15 ` Heinrich Schuchardt
2021-11-09 18:18 ` Tom Rini
2021-11-09 21:47 ` Andre Przywara
2021-11-09 23:45 ` Grant Likely
-- strict thread matches above, loose matches on Subject: below --
2023-01-28 8:57 Heinrich Schuchardt
2023-01-30 18:13 ` Tom Rini
2023-01-30 18:30 ` Tom Rini
2023-01-31 12:03 ` Ilias Apalodimas
2023-01-31 14:16 ` Simon Glass
2023-01-31 14:48 ` Heinrich Schuchardt
2023-01-31 15:07 ` Tom Rini
2023-02-01 8:32 ` Rasmus Villemoes
2023-02-01 9:00 ` Heinrich Schuchardt
2023-02-02 8:17 ` Etienne Carriere
2023-02-02 17:12 ` Simon Glass
2023-02-02 17:22 ` Tom Rini
2023-02-03 2:15 ` Simon Glass
2023-02-03 7:30 ` Rasmus Villemoes
2023-02-07 14:59 ` Michael Walle
2023-02-07 15:08 ` Heinrich Schuchardt
2023-02-07 15:29 ` Michael Walle
2023-02-07 15:30 ` Heinrich Schuchardt
2023-02-07 15:34 ` Michael Walle
2023-02-03 15:51 ` Tom Rini
2023-02-04 0:20 ` Simon Glass
2023-02-01 12:49 ` Mark Kettenis
2023-02-01 15:21 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ab55ce9823874154ef5b2d2dace38075@walle.cc \
--to=michael@walle.cc \
--cc=agraf@csgraf.de \
--cc=andre.przywara@arm.com \
--cc=heinrich.schuchardt@canonical.com \
--cc=mark.kettenis@xs4all.nl \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox