Shutdown deadlock after failed GPU init on Lenovo Legion 83LT (RTX 5070 Max-Q, 610.57.04)

Shutdown deadlock after failed GPU init on Lenovo Legion 83LT (RTX 5070 Max-Q, 610.57.04)

Summary

On a hybrid-graphics Lenovo Legion (AMD iGPU primary, RTX 5070 Max-Q secondary), the
NVIDIA driver fails to initialize the dGPU because the system firmware does not answer
its platform power/thermal queries. The driver then attempts to remove the device, and
that removal fails with a non-zero usage count, leaving the device orphaned — no
driver bound, still in D0. On shutdown the kernel retries this teardown and deadlocks:

task shutdown:1 blocked for more than 122 seconds
      (blocked on a mutex)
watchdog: watchdog0: watchdog did not stop!

Every shutdown and reboot hangs for 2–4 minutes and requires a hard power-off.

The failed init is arguably a firmware gap. The deadlock is not. A driver that
cannot initialize a GPU should fail cleanly and release it, not leave a device in a
state that blocks systemd-shutdown indefinitely.

System

Model	Lenovo 83LT — Legion Pro 5 16ADR10 (CN: Legion R7000P ADR10)
BIOS	RLCN32WW, release 1.32, 2025-11-25 (latest available)
EC firmware	1.31
dGPU	NVIDIA GB206M [GeForce RTX 5070 Max-Q / Mobile] [10de:2d58] (rev a1) @ 0000:01:00.0
iGPU	AMD Raphael [1002:164e] (rev d8) @ 0000:05:00.0 — drives the internal panel
Driver	nvidia-open-dkms 610.57.04-1, nvidia-utils 610.57.04-1
Kernel	7.1.9-arch1-2 (current)
OS	Omarchy 4.0.1 (Arch Linux), Hyprland / Wayland
Secure Boot	disabled

Log evidence

Driver load, then both SBIOS queries fail:

kernel: NVRM: loading NVIDIA UNIX Open Kernel Module for x86_64  610.57.04  Release Build
kernel: NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Invalid data passed
        [NV_ERR_INVALID_DATA] (0x00000025) returned from PlatformRequestHandler
        failed to get target temp from SBIOS @ platform_request_handler_ctrl.c:2174
kernel: NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Invalid data passed
        [NV_ERR_INVALID_DATA] (0x00000025) returned from PlatformRequestHandler
        failed to get platform power mode from SBIOS @ platform_request_handler_ctrl.c:2117

Removal then fails, ~28 seconds later, on every boot:

kernel: NVRM: Attempting to remove device 0000:01:00.0 with non-zero usage count!

Resulting steady state — module loaded, but no driver bound and the device left powered:

$ ls /sys/bus/pci/devices/0000:01:00.0/driver
  No such file or directory
$ cat /sys/bus/pci/devices/0000:01:00.0/power_state
  D0
$ nvidia-smi
  No devices were found

This firmware also logs an unrelated-looking ACPI defect on every boot, noted only for
completeness:

kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.PB2], AE_NOT_FOUND
        (20251212/dswload2-162)
kernel: ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20251212/psobject-220)

I do not believe this is GPU-related. The dGPU's ACPI object on this machine is
\_SB_.PCI0.GPP0.PEGP (per nouveau's Optimus DSM detection), so PB2 is some other
bridge. Mentioned so it can be discounted rather than chased.

The shutdown:1 blocked-task trace and watchdog0 message appear on the console only.
They are never written to the journal, because the hang occurs after
systemd-journal-flush releases /var.

Correlation

Shutdown duration measured as the gap between the last journal write of one boot and the
first of the next:

boot	shutdown gap	nvidia driver loaded
-2	139 s	yes
-1	257 s	yes
0	31 s	no

31 s is a normal reboot cycle for this machine. The correlation is exact across every
boot tested: driver loaded → hang, driver absent → clean.

Reproduction

1. Boot this hardware with nvidia-open-dkms 610.57.04 installed.
2. Observe the two PlatformRequestHandler SBIOS failures, then
   Attempting to remove device ... with non-zero usage count!.
3. Confirm the orphaned state: no driver symlink at 0000:01:00.0, power_state = D0,
   nvidia-smi reports no devices.
4. systemctl reboot.
5. Shutdown stalls; console shows task shutdown:1 blocked for more than 122 seconds
   followed by watchdog: watchdog0: watchdog did not stop!.

Note: the driver loads even when blacklisted, because any GL/CUDA/Vulkan client invokes
the setuid helper /usr/bin/nvidia-modprobe, which loads modules by explicit name.
blacklist only suppresses alias resolution. On this system two independent callers were
identified — Hyprland's EGL vendor probe at session start, and a userspace daemon's CUDA
runtime probe.

Workaround

Block the module at the install level, which — unlike blacklist — also applies to
explicit by-name loads:

# /etc/modprobe.d/nvidia-shutdown-block.conf
install nvidia /bin/false

Shutdown time drops from 139–257 s to 31 s. No functionality is lost, because the dGPU
was already unusable (nvidia-smi: no devices, no driver bound).

Ruled out during investigation

• supergfxd / GPU-switching daemon — not installed on this system.

• Userspace holding the device open — a reboot performed with the module refcount
  reduced to its floor (2, i.e. only nvidia_uvm + nvidia_modeset) and zero processes
  holding /dev/nvidia* file descriptors still hung. The stale reference is internal
  to the driver, left by the failed removal — not a userspace fd leak.

• Hardware fault — the GPU enumerates correctly and negotiates PCIe 5.0 x8 at
  16.0 GT/s. Additionally, nouveau reaches considerably further than this driver
  before failing: it identifies the chip (NVIDIA GB206 (1b6000a1)), successfully loads
  GSP firmware (gsp: RM version: 570.144), and exchanges messages with the GSP before
  its own init fails:

  nouveau 0000:01:00.0: NVIDIA GB206 (1b6000a1)
  nouveau 0000:01:00.0: gsp: RM version: 570.144
  nouveau 0000:01:00.0: gsp:msg fn:4130 len:0x28/0x8 res:0x0 resp:0x0
  nouveau 0000:01:00.0: gsp:msg fn:4097 len:0x20/0x0 res:0x65 resp:0x65
  nouveau 0000:01:00.0: gsp: init failed, -22
  nouveau 0000:01:00.0: probe with driver nouveau failed with error -22
  

  nouveau does not work either, so this is not a workaround — but it does establish that
  the GPU is reachable, its firmware boots, and GSP communication is possible on this
  hardware. Whatever blocks nvidia.ko is upstream of the device being unusable.

• Secure Boot / module signing — Secure Boot is disabled; the signature warning is a
  taint only.

• Outdated firmware or kernel — both are the latest available as of 2026-08-30.

• The watchdog itself — both wdat_wdt and sp5100_tco report state=inactive,
  nowayout=0. watchdog0: watchdog did not stop! is a downstream symptom of the stalled
  shutdown, not its cause.

Request

Two things would help, in order of importance:

1. Make the failure path safe. When PlatformRequestHandler cannot obtain platform
   data from the SBIOS, the driver should abort initialization and release the device
   cleanly rather than leaving it with a non-zero usage count. A GPU that cannot be
   initialized should not be able to deadlock system shutdown.
2. Degrade gracefully on absent platform data. This firmware does not answer the
   PlatformRequestHandler queries for target temperature or platform power mode.
   Treating those as non-fatal — falling back to driver-side defaults — would plausibly
   make the GPU usable on this hardware rather than merely stopping it from hanging
   shutdown. That the GSP boots fine under nouveau suggests the device itself is
   capable; it is the platform-integration layer that fails.

Happy to supply additional logs, run instrumented builds, or test patches on this hardware.

Start by tracing the PlatformRequestHandler failures and the subsequent device-removal path that reports a non-zero usage count. Reproduce the boot and shutdown sequence with the listed hardware and logs. Done means failed initialization releases the device cleanly and shutdown no longer deadlocks; the issue also proposes handling absent platform data without making those queries fatal.