Reporting a related case on a different Lenovo model with the same Phoenix/gfx1103 GPU family and same 6.8.x kernel track — flagging because amdgpu.runpm=0 has NOT fully resolved my case the way it did here, which may indicate a distinct-but-related issue worth tracking separately.
System Information Model: Lenovo ThinkPad T14s Gen 4, Type 21F9CTO1WW CPU: AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics (Phoenix, gfx1103_r1) BIOS: R2EET49W (1.30), 03/18/2026 OS: Ubuntu 22.04.5 LTS (Xubuntu/XFCE 4.16.0) Kernel: 6.8.0-136-generic (HWE track — this is the ceiling for 22.04; no 6.17/linux-oem-24.04 path exists on this release to test the upgrade route documented in comment #6) linux-firmware: 20220329.git681281e4-0ubuntu3.42 Storage: Samsung MZVL21T0HDLU-00BLL (1TB NVMe), firmware 6L2QGXD7 Why I'm flagging this as possibly distinct Comment #6 confirms amdgpu.runpm=0 gives fully reliable, deterministic boots on the IdeaPad Slim 3 (Phoenix/Radeon 740M) — the freeze reportedly does not recur once the parameter is set, across both 6.8.0-100 and 6.17.0-22. On my hardware (Phoenix/Radeon 780M), amdgpu.runpm=0 has been active continuously since 2026-08-13, and the boot freeze still recurs intermittently — roughly once every 4–11 cold boots — rather than being fully eliminated. This is a different pattern than the deterministic freeze-every-time-without-the-parameter behavior described here, which makes me wonder whether this is genuinely the same root cause, or a related-but-separate amdgpu/Phoenix boot-path issue that happens to share the same workaround as a partial mitigation. Symptom Blank screen with blinking cursor top-left, immediately after selecting the boot entry at GRUB, before any kernel/userspace logging begins. Fully unresponsive, requires hard power-off. Not reproducible on warm reboots — only cold boots. Steps taken (chronological) BIOS updated 0.1.24 → 0.1.30 — no change in frequency. Added nvme_core.default_ps_max_latency_us=5500 — hang recurred afterward. Tested GRUB_TERMINAL=console to rule out GRUB gfxterm/amdgpu handoff — hang recurred, since reverted (ruled out). Added amdgpu.runpm=0 (based on this bug) on 2026-08-13 — hang has recurred at least twice since (2026-08-20, 2026-08-24), so the workaround that fully resolved comment #6's case has only partially helped, if at all, in mine. Currently also testing amdgpu.dcdebugmask=0x10 (disables PSR) alongside runpm=0, added 2026-08-25 — result pending. Current kernel command line text quiet nvme_core.default_ps_max_latency_us=5500 amdgpu.runpm=0 amdgpu.dcdebugmask=0x10 usbcore.autosuspend=-1 i8042.nomux=1 i8042.reset i2c_hid.polling_mode=1 Log evidence No journal entries are ever produced for the failed boots — journalctl -b -1 -p err..emerg, journalctl -b -1 -u lightdm, and Xorg.0.log all show clean output on the subsequent successful boot, confirming the freeze happens before systemd-journald initializes (GRUB-to-kernel handoff or very early kernel/initramfs stage). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2141725 Title: Boot freezes unless amdgpu.runpm=0 on Lenovo IdeaPad Slim 3 (Phoenix / Radeon 740M) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2141725/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
