[9front] Thinkpad T14 hung boot

[9front] Thinkpad T14 hung boot

[akw]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

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.

Thanks!
Aidan

[-- Attachment #2: screen.jpg --]
[-- Type: image/jpeg, Size: 427596 bytes --]

Re: [9front] Thinkpad T14 hung boot

[Michael Forney]

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.