NetBSD Problem Report #55954

From www@netbsd.org  Sun Jan 24 08:33:23 2021
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id EFFAB1A923B
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 24 Jan 2021 08:33:22 +0000 (UTC)
Message-Id: <20210124083321.657FA1A923C@mollari.NetBSD.org>
Date: Sun, 24 Jan 2021 08:33:21 +0000 (UTC)
From: aza.sea.agenda@gmail.com
Reply-To: aza.sea.agenda@gmail.com
To: gnats-bugs@NetBSD.org
Subject: bootx64.efi hangs up on boot
X-Send-Pr-Version: www-1.0

>Number:         55954
>Category:       port-amd64
>Synopsis:       bootx64.efi hangs up on boot
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-amd64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 24 08:35:00 +0000 2021
>Last-Modified:  Sun Feb 07 00:50:01 +0000 2021
>Originator:     Aleksey Arens
>Release:        9.1_STABLE
>Organization:
>Environment:
NetBSD HOSTNAME_REDACTED 9.1_STABLE NetBSD 9.1_STABLE (XEN3_DOM0.STAGING.01) #5: Thu Jan 21 23:27:04 UTC 2021  root@HOSTNAME_REDACTED:/usr/obj/sys/arch/amd64/compile/XEN3_DOM0 amd64
>Description:
The system hangs after displaying "mem[ ... ]" array on console when full UEFI boot is performed.  The BIOS boot and legacy boot options were disabled in the firmware.

The affected system is a Lenovo 33474HU (ThinkPad Twist) laptop.

>How-To-Repeat:
Attempt to boot the affected system from a USB flash in UEFI-only mode.
>Fix:
So far, I have workaround available, that is confirmed to work.

---8<---

--- a/sys/arch/i386/stand/efiboot/efiboot.c
+++ b/sys/arch/i386/stand/efiboot/efiboot.c
@@ -91,8 +91,8 @@ efi_main(EFI_HANDLE imageHandle, EFI_SYSTEM_TABLE *systemTable)

        efi_memory_probe();
        efi_disk_probe();
-       efi_pxe_probe();
-       efi_net_probe();
+       /* efi_pxe_probe(); */
+       /* efi_net_probe(); */

        status = uefi_call_wrapper(BS->SetWatchdogTimer, 4, 0, 0, 0, NULL);
        if (EFI_ERROR(status))


---8<---

A basic investigation had revealed that the hang up occurs at the following place in efiboot.c:359:

---8<---

		status = uefi_call_wrapper(BS->OpenProtocol, 6, handles[i],
		    &SimpleNetworkProtocol, (void **)&net, IH, NULL,
		    EFI_OPEN_PROTOCOL_EXCLUSIVE);
		if (EFI_ERROR(status)) {
			printf("Unable to open network interface %" PRIuMAX
			    " for exclusive access: %" PRIxMAX "\n",
			    (uintmax_t)i, (uintmax_t)status);
		}


---8<---

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-amd64/55954: bootx64.efi hangs up on boot
Date: Sun, 24 Jan 2021 10:55:40 +0100

 Your UEFI firmware is broken, check if there is an update available.

 Martin

From: Aleksey Arens <aza.sea.agenda@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-amd64/55954: bootx64.efi hangs up on boot
Date: Fri, 5 Feb 2021 17:34:55 -0800

 >
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@netbsd.org
 > Cc:
 > Subject: Re: port-amd64/55954: bootx64.efi hangs up on boot
 > Date: Sun, 24 Jan 2021 10:55:40 +0100
 >
 >  Your UEFI firmware is broken, check if there is an update available.
 >
 >  Martin
 >

 I've flashed the new version of firmware (ca. 2019) from
 https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-twist-series-laptops/thinkpad-twist-s230u/3347/downloads/driver-list/component?name=BIOS%2FUEFI
 .

 Unfortunately, the problem persists even after a successful firmware
 update.  I suppose a workaround could be hacked-around.  However, if
 the machine is left in BIOS-only mode (not just UEFI + legacy
 support), then it successfully boots with a basic gpt biosboot -A ...
 and installboot ... setup.  Thus, I doubt that whatever workaround
 would be worth the effort.

 May I suggest, as an option, an ability to build more than one flavor
 of the bootable efi binary?

From: Aleksey Arens <aza.sea.agenda@gmail.com>
To: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org, 
	netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-amd64/55954: bootx64.efi hangs up on boot
Date: Fri, 5 Feb 2021 20:02:32 -0800

 Please allow me to suggest an alternate -- arguably better --
 possibility that I have in mind.  First, the bootx64.efi could
 initialize the local disks.  Then, it would look into the config file.
 If an option to disable network init is passed, then no network init
 is performed.  Otherwise, the network is initialized.  Since it's
 never the case that the boot menu is generated by performing any
 network-related actions, this approach is sound.  It would also
 conservatively preserve the old behaviour for all old configurations.

 If this approach is found to be amenable, I could make myself
 available to implement it.

From: matthew green <mrg@eterna.com.au>
To: Aleksey Arens <aza.sea.agenda@gmail.com>
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Subject: re: port-amd64/55954: bootx64.efi hangs up on boot
Date: Sat, 06 Feb 2021 17:17:11 +1100

 Aleksey Arens writes:
 > Please allow me to suggest an alternate -- arguably better --
 > possibility that I have in mind.  First, the bootx64.efi could
 > initialize the local disks.  Then, it would look into the config file.
 > If an option to disable network init is passed, then no network init
 > is performed.  Otherwise, the network is initialized.  Since it's
 > never the case that the boot menu is generated by performing any
 > network-related actions, this approach is sound.  It would also
 > conservatively preserve the old behaviour for all old configurations.
 >
 > If this approach is found to be amenable, I could make myself
 > available to implement it.

 this might work if it was only performed only when bootx64.efi
 is loaded from a disk, vs via pxe or something.  they may not
 even be local disks at all in this case.

 your "never the case" claim is not quite true, but perhaps it
 can be adjusted to suit.. i can't really judge whether it is
 actually feasible idea in general.

 thanks.


 .mrg.

From: Aleksey Arens <aza.sea.agenda@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org, 
	netbsd-bugs@netbsd.org
Subject: Re: port-amd64/55954: bootx64.efi hangs up on boot
Date: Sat, 6 Feb 2021 13:56:18 -0800

 Hello Matthew,

 >  this might work if it was only performed only when bootx64.efi
 >  is loaded from a disk, vs via pxe or something.  they may not
 >  even be local disks at all in this case.

 As diskless(8) suggests, in the PXE netboot case, the network has to
 be used anyway for
 subsequent steps.  What this means in practice is that in general for
 the machine in
 question the PXE netbooting is not going to be an option -- it would
 simply hang up.

 A diskless(8) also vaguely suggests that the configuration for
 bootloader in the case of
 PXE boot is supplied by means other than reading a local config file.

 In general, the local config is used if the boot is performed from a
 local disk, with the
 kernel residing locally.  This behaviour does not involve the use of a
 network, and it is
 traditional.  So, it is a reasonable to require that network-related
 functionality is only
 be initialized whence a non-traditional behaviour is desired for local
 disk boots, whence
 a kernel is to be loaded from the network.  That would not be a common
 configuration.

From: matthew green <mrg@eterna.com.au>
To: Aleksey Arens <aza.sea.agenda@gmail.com>
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Subject: re: port-amd64/55954: bootx64.efi hangs up on boot
Date: Sun, 07 Feb 2021 11:47:43 +1100

 Aleksey Arens writes:
 > Hello Matthew,
 >
 > >  this might work if it was only performed only when bootx64.efi
 > >  is loaded from a disk, vs via pxe or something.  they may not
 > >  even be local disks at all in this case.
 >
 > As diskless(8) suggests, in the PXE netboot case, the network has to
 > be used anyway for
 > subsequent steps.  What this means in practice is that in general for
 > the machine in
 > question the PXE netbooting is not going to be an option -- it would
 > simply hang up.

 this is your machine, yes.  what i mean is for something we could
 commit to the tree for everyone to use.  if it's changed to loading
 boot.cfg to determine what types of interface to skip setting up,
 then it should be sufficient to handle your case, as long as this
 can actually work.  it's not clear to me that we know this info at
 the time the calls are made, so it may be not simple or possible.

 we do not want to break any existing functionality, and it *is* the
 case that people use network from /boot loaded locally sometimes
 (i've done this), so any chance would be best to be non-default,
 as a workaround for broken platforms.  (it remains the case that
 the most likely root cause if broken firmware.)


 .mrg.

Home	PR Database Search