public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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/

  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