9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Michael Forney <mforney@mforney.org>
To: 9front@9front.org
Cc: akw@oneirism.org
Subject: Re: [9front] Thinkpad T14 hung boot
Date: Fri, 18 Nov 2022 20:20:15 -0800	[thread overview]
Message-ID: <3U1941GU6D3PQ.3T4BU9350MI49@mforney.org> (raw)
In-Reply-To: <4833AF9EC7D2CF63D5C30CC6057A1DA9@oneirism.org>

akw@oneirism.org wrote:
> Has anyone else had any experience with the T14 (gen1), or maybe
> similar, newer Ryzen based thinkpads? It always exhibits the
> behavior as evidenced in the attachement. I can only boot from a
> USB drive if I 'secure wipe' the NVME disk *and then* load the
> UEFI to default settings, at which point I can install it as
> normal, and then reboot back to the same problem (which "hangs"
> indefinitely). I have tried most plan9.ini boot combinations
> (*acpi=0, nousb options, and a select other few), but with no
> success. I have also tried some combinations of UEFI settings,
> but those also do not work.
> 
> I am pretty certain it is something with this troublesome UEFI,
> and was just wondering if anyone else had the same/similar issues?
> 
> My uneducated guess is that it's related to the NVME disk, as it
> is usually the next boot message there.

I have the same laptop, and until recently it had been working fine
with 9front. However, a little while ago I updated the BIOS and
started having the same issue as you.

I determined the hang was when aux/kbdfs tried to open /dev/scancode,
since devsd's walk function calls nvmeenable, and sdnvme doesn't
detect device errors during initialization and waits indefinitely
for the identify command to complete.

The device error was caused (as cinap predicted) by the IOMMU being
enabled, and blocking the device's attempts to access memory. This
prevented it from completing the identify command.

The root cause (as you predicted) was the UEFI being overly strict
about GetMemoryMap and ExitBootServices, and requiring that the
MapKey we pass to ExitBootServices be obtained *immediately* before
the call.

To get this working, you can build a new bootx64.efi with the patch
posted to this list a few days ago (not committed yet, we are still
working out some stylistic things). Or, you can use some multiboot
loader (like grub) to load the kernel instead. Using multiboot
requires a very recent kernel to fix multiboot with a 64-bit
framebuffer address.

      reply	other threads:[~2022-11-19  4:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-26 19:35 akw
2022-11-19  4:20 ` Michael Forney [this message]

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=3U1941GU6D3PQ.3T4BU9350MI49@mforney.org \
    --to=mforney@mforney.org \
    --cc=9front@9front.org \
    --cc=akw@oneirism.org \
    /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;
as well as URLs for NNTP newsgroup(s).