Bug 276011 - Lenovo P15v Gen3 (AMD) - FreeBSD14-RELEASE will not boot for installation
Summary: Lenovo P15v Gen3 (AMD) - FreeBSD14-RELEASE will not boot for installation
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 14.0-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL: https://forums.freebsd.org/threads/ho...
Keywords:
: 276010 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-12-30 02:42 UTC by Phil Vuchetich
Modified: 2024-01-15 19:56 UTC (History)
3 users (show)

See Also:


Attachments
Lenovo BIOS - system information report (32.98 KB, text/plain)
2024-01-02 18:42 UTC, Phil Vuchetich
no flags Details
Linux - lspci -v output (14.70 KB, text/plain)
2024-01-02 18:43 UTC, Phil Vuchetich
no flags Details
Linux - dmesg output (123.45 KB, text/plain)
2024-01-02 18:47 UTC, Phil Vuchetich
no flags Details
ddb trace after using unset hint.uart.1.at (204.59 KB, image/jpeg)
2024-01-15 19:56 UTC, Phil Vuchetich
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Phil Vuchetich 2023-12-30 02:42:21 UTC
This is very likely a hardware-specific issue for the Lenovo P15v Gen3 (AMD Ryzen 7 PRO). The model number is 21EM0039US.

When installing from FreeBSD14-RELEASE-amd64-dvd1 on a Lenovo P15v Gen3 (AMD), the system freezes after booting to the line "battery0: <ACPI Control Method Battery> on acpi0". (screenshot attached showing a portion of the screen). The system hangs indefinitely (at least tens of minutes before I turn it off).

Per a comment on the FreeBSD forum, it may be an issue with the NVME controller, which might be Intel RST (I have not seen a definitive spec.), with the recommendation to change the BIOS config to use AHCI instead of RST.

However, the BIOS settings do not include any storage controller settings.  Previous versions (P15v Gen1, possibly Gen2) did allow BIOS to change the storage controller between RST and AHCI, and Lenovo provided a PDF guide to change to AHCI for running Ubuntu 20.04 on the Gen1 version.

I have been able to install Windows 10, 11, and Debian 12.4.0 on this PC. Assuming that the issue is an unsupported component, if there is information that can be obtained from one of those OS that would be helpful, please let me know.

I would suggest that this is a very low priority issue, and that the workaround is to simply use a different model computer that is known to work until the underlying issue is identified and resolved.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2023-12-30 07:44:11 UTC
*** Bug 276010 has been marked as a duplicate of this bug. ***
Comment 2 Ed Maste freebsd_committer freebsd_triage 2024-01-02 14:59:59 UTC
Two things you can try, to get more information:

1. Try with the latest 15.0 snapshot image (from https://download.freebsd.org/snapshots/ISO-IMAGES/15.0/) - it's possible that something was fixed after 14.0.

2. See if a verbose boot gives you more information - in the loader choose the boot options menu and then choose verbose boot. You can try this on the 15 snapshot.
Comment 3 Phil Vuchetich 2024-01-02 16:53:52 UTC
Thanks,

Trying FreeBSD-15.0-CURRENT-amd64-20231228-fb03f7f8e30d-267242-memstick.img (dated 2023-12-28)

verbose boot got stuck after the message
"uart0 failed to probe at port 0x3f8 irq 4 on isa0"

A search of that message led me to on old forum post:

https://forums.freebsd.org/threads/boot-hangs-on-cherrytrail-uefi-system-installer-preinstalled-stick-no-dmesg-written.57321/

Trying "unset hint.uart.0.at" gets stuck at "ppc0 failed to probe at irq 7 on isa0"

Trying "unset hint.uart.1.at" is partially successful - it will boot to single user prompt or to the installer screen (depending on boot preferences), but the internal keyboard/touchpad do not work. An external keyboard/mouse does work.

It appears that cause may be unrecognized UARTS that might need a similar solution to bug ID 207910 (adding specific UARTS).

Next step for me: I'll collect UART information from hardware diagnostics (BIOS app that is included with system) and a Linux-based system that boots and run 'lspci -v', and see which boot hints get the keyboard/touchpad working.
Comment 4 Phil Vuchetich 2024-01-02 18:42:32 UTC
Created attachment 247412 [details]
Lenovo BIOS - system information report
Comment 5 Phil Vuchetich 2024-01-02 18:43:36 UTC
Created attachment 247413 [details]
Linux - lspci -v output
Comment 6 Phil Vuchetich 2024-01-02 18:47:30 UTC
Created attachment 247414 [details]
Linux - dmesg output

3 attachments (Lenovo BIOS System information output, Linux lspci -v, Linux dmesg) included to help identify the specific device(s) not recognized by FreeBSD.

Status - still work in progress.
Comment 7 John Baldwin freebsd_committer freebsd_triage 2024-01-12 19:09:07 UTC
Can you try to take a photo of the verbose dmesg to get that the messages before the freeze?  Generally speaking the last line you see isn't really related as it's probably a hang in the next device that hasn't printed a message yet.  If you can capture more of the verbose dmesg that might help with debugging the issue.  Another option if you are using a 15.0-current snapshot is to try Ctrl-Alt-Escape to see if you can break into the DDB debugger.  If you do get a db> prompt, please get a stack trace with 'tr' and take some pictures of the stack trace.
Comment 8 Phil Vuchetich 2024-01-15 19:56:12 UTC
Created attachment 247682 [details]
ddb trace after using unset hint.uart.1.at

Retesting on FreeBSD-15.0-CURRENT-amd64-20240111-a61d2c7fbd3c-267507-disc1.iso
Verbose boot, single user, boot loader "unset hint.uart.1.at", "boot"        
This gets to a single user shell.
Note: internal keyboard and touchpad do not work. External USB keyboard works.
(partial success as before).

Then: <CTRL>-<ALT>-<ESC> from external keyboard
db> tr
screenshot output attached (9 lines)

Notes on additional unsuccessful tests:
1. I tried "boot -d" to immediately get to ddb, which gets to the DDB prompt, but neither internal nor external keyboard works (it might just be they are not initialized).
2. Without using the "unset hint.uart.1.at", the system freezes in the same way as before prior to getting to a shell.