From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE223C433F5 for ; Tue, 9 Nov 2021 14:54:35 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DA61860F4B for ; Tue, 9 Nov 2021 14:54:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DA61860F4B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 20F0A8383A; Tue, 9 Nov 2021 15:54:33 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=walle.cc header.i=@walle.cc header.b="EUV0sq6t"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id AB87F83924; Tue, 9 Nov 2021 15:54:31 +0100 (CET) Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id A4E9483665 for ; Tue, 9 Nov 2021 15:54:28 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=michael@walle.cc Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id B098322246; Tue, 9 Nov 2021 15:54:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1636469668; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nwtWnaYTRry7NmsKVIoFqEO7vFcOoUwho72qCUcU6Jo=; b=EUV0sq6tT81JAtEFRcP5zmoumgEnofC+kuDTmCI2fBPZmrotAmmpNTworfyBHIEA/l0LoK LIIs0Q4WTzL7eLlHM+LfpMukd9eE9jrgJSGgzA7M6/dCIbn0BSGeiq4mTHRVuNBf2JsmZC VSrkpvuCrOlwfNEymnZB8dL0FthEJXE= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 09 Nov 2021 15:54:27 +0100 From: Michael Walle To: Mark Kettenis 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() In-Reply-To: References: <20211109101901.24015-2-heinrich.schuchardt@canonical.com> <20211109142017.2834294-1-michael@walle.cc> User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: michael@walle.cc X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Am 2021-11-09 15:46, schrieb Mark Kettenis: >> From: Michael Walle >> 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/