Reproducible Xid 79 / GSP heartbeat timeout while nvidia-powerd is issuing the same GSP_RM_CONTROL request
Suggested title
[610.43.02][RTX 5060 Laptop][Lenovo 83LY] Reproducible Xid 79 and GSP heartbeat timeout in nvidia-powerd GSP_RM_CONTROL (0x2080a613)
Summary
On a Lenovo Legion Y7000 IRX10 / Lenovo machine type 83LY with an NVIDIA
GeForce RTX 5060 Laptop GPU, enabling nvidia-powerd makes a short,
GPU-heavy TensorRT workload reproducibly black-screen the machine.
The GPU disappears from PCIe with Xid 79. The display, keyboard and virtual
terminals stop responding, so a forced power-off is required. Five captured
failures have the same caller (nvidia-powerd) and the same incomplete GSP
RPC:
GSP_RM_CONTROL
data0 0x000000002080a613
data1 0x0000000000013840
The problem reproduced across:
- NVIDIA 595.84 with Linux 6.8.0-136 on Ubuntu 22.04
- NVIDIA 610.43.02 open kernel modules with Linux 7.0.0-28 on Ubuntu 24.04.4
- Lenovo BIOS QNCN38WW (2026-05-21), the latest BIOS offered for this machine
With nvidia-powerd disabled, the GPU is limited to its 50 W base TGP and
the same computer is stable. The GPU is also stable under long CUDA workloads
on Windows on the same hardware.
System information
Laptop: Lenovo Legion Y7000 IRX10
Machine type: LENOVO 83LY / LNVNB161216
BIOS: QNCN38WW, 2026-05-21
OS: Ubuntu 24.04.4 LTS
Kernel: 7.0.0-28-generic
GPU: NVIDIA GeForce RTX 5060 Laptop GPU
PCI ID: 10de:2d59
Subsystem: Lenovo 17aa:3e2e
Driver: nvidia-open 610.43.02
Desktop: GNOME/Wayland, dGPU display mode
The kernel 7.0 Lenovo WMI drivers are present and loaded:
lenovo_wmi_gamezone
lenovo_wmi_other
lenovo_wmi_capdata
lenovo_wmi_helpers
lenovo_wmi_events
/sys/firmware/acpi/platform_profile works and Fn+Q changes profiles.
Reproduction
-
Select the Lenovo performance profile with Fn+Q.
-
Start
nvidia-powerd. It establishes its D-Bus connection and raises the
GPU power ceiling from 50 W to as much as 115 W:sudo systemctl start nvidia-powerd.service journalctl -u nvidia-powerd.service -b nvidia-smi -
Start official Sabaki 0.60.0 with Chromium GPU rendering disabled:
ELECTRON_ENABLE_LOGGING=1 \ ~/Applications/sabaki-v0.60.0-linux-x64.AppImage \ --disable-gpu --enable-logging=stderr -
Configure KataGo 1.16.5, TensorRT 10.14.1, FP16, 10 search threads, and
thekata1-zhizi-b40c768nbt-s11272M-d5935M.bin.gzmodel. -
Set KataGo as the opponent, play
B Q16, and let KataGo respond using:kata-genmove_analyze W 50 -
On the latest captured run, KataGo completed 6,409 visits and returned
D16after 21.7584 seconds. Two seconds later the GPU fell off the bus and
the entire display stopped responding.nvidia-powerd-xid79-evidence-20260725-public-redacted.zip (65.6 KB)
nvidia-bug-report-public-redacted.log.gz (741.6 KB)
The incidence is high and this sequence has reproduced the failure repeatedly.
Exact latest timeline
19:33:01 workload begins 32.51 W, 66 C, 99% GPU
19:33:03 114.17 W, 80 C, 100% GPU
19:33:05 113.68 W, 85 C, 99% GPU
19:33:09 104.40 W, 87 C, 99% GPU
19:33:15 98.36 W, 89 C, 99% GPU
19:33:22 KataGo returns D16 (6409 visits)
19:33:23 89.86 W, 90 C, 99% GPU
19:33:24 Xid 79, GPU has fallen off the bus
19:33:25 nvidia-smi can no longer access the GPU
There is no NVIDIA thermal-shutdown Xid. Other sustained workloads have
previously reached comparable temperatures without failure. The repeatable
in-flight RPC and caller are more specific than temperature or application
load alone.
Critical kernel evidence
Every captured failure contains:
NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.
NVRM: _kgspLogRpcSanityCheckFailure: GPU0 sanity check failed 0xf
waiting for RPC response from GSP.
Expected function 76 (GSP_RM_CONTROL)
NVRM: -1 76 GSP_RM_CONTROL ...
data0 0x000000002080a613
data1 0x0000000000013840
ts_end 0x0000000000000000
CPU: ... PID: ... Comm: nvidia-powerd
NVRM: _kgspRpcRecvPoll: GSP RM heartbeat timed out
NVRM: _kgspRpcRecvPoll: LibOS heartbeat timed out
NVRM: Xid (PCI:0000:01:00): 154,
GPU recovery action changed ... to OS Reboot
The immediately preceding occurrence of the same control request completes
normally in roughly 2 ms. The next identical request remains incomplete when
the GPU disappears:
-1 GSP_RM_CONTROL ... 0x2080a613 0x13840 ... no completion
-5 GSP_RM_CONTROL ... 0x2080a613 0x13840 ... 2141 us
Five recorder logs show the same signature:
2026-07-25 14:19:27 Linux 6.8.0-136 Comm: nvidia-powerd Xid 79
2026-07-25 15:17:06 Linux 6.8.0-136 Comm: nvidia-powerd Xid 79
2026-07-25 16:39:13 Linux 6.8.0-136 Comm: nvidia-powerd Xid 79
2026-07-25 17:14:04 Linux 6.8.0-136 Comm: nvidia-powerd Xid 79
2026-07-25 19:33:24 Linux 7.0.0-28 Comm: nvidia-powerd Xid 79
Other firmware messages
At NVIDIA driver initialization:
failed to get target temp from SBIOS
failed to get platform power mode from SBIOS
At ACPI initialization:
ACPI BIOS Error (bug): Could not resolve symbol [\_TZ.ETMD], AE_NOT_FOUND
ACPI Error: Aborting method \_SB.IETM._OSC due to previous error
The current nvidia-powerd service itself starts without a reported error:
nvidia-powerd version:2.0 (build 1)
DBus Connection is established
Workarounds tested
- Disabling
nvidia-powerdavoids the captured failure, but limits the GPU to
50 W instead of up to 115 W. sudo nvidia-smi -pl 100 --scope=0is not supported on this laptop GPU.- Updating BIOS to QNCN38WW did not fix the failure.
- Updating Ubuntu, Linux 6.8 to 7.0, and NVIDIA 595.84 to 610.43.02 did not
change the failing GSP control request. - Sabaki was run with
--disable-gpu, so Electron GPU rendering is not
required for the reproduction.
Questions for NVIDIA
- What RM control operation does
0x2080a613identify? - Is this a known
nvidia-powerd/ Dynamic Boost / GSP firmware issue on
Blackwell laptop GPUs? - Is there a supported way to keep the higher GPU TGP while disabling the
failing dynamic power-control operation? - Is there a driver or GSP firmware build containing a fix that can be tested?
Attachments
nvidia-bug-report.log.gz- Five
kernel-*.logrecorder files live-20260725-191507.log20260725-193216-60247CAA.log(KataGo GTP log)sabaki-kernel7-test.log