You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please confirm this issue does not happen with the proprietary driver (of the same version)
Not tested. Blackwell (GB205) requires the open kernel modules; the Arch repositories ship nvidia-open-dkms only for this GPU. I can test the proprietary .run driver on request,
but reproduction is not yet deterministic (see Bug Incidence).
Operating System and Version
Arch Linux (rolling), GNOME 50.4 on Wayland (mutter 50.4-1, gnome-shell 1:50.4-1)
Kernel Release
Linux 7.1.8-arch1-3 x86_64
Please confirm you are running a stable release kernel
Single display on the NVIDIA GPU (DP-3). Kernel cmdline includes nvidia_drm.modeset=1.
Describe the bug
The GPU's PMU halts while the system is idle, and the GSP never recovers. The desktop
freezes permanently; the rest of the system keeps running normally.
Sequence (2026-08-19, all times CEST):
21:48:01.130 Xid 62 — 324c1547 0000ca08 00000000 20726198 20725344 207254b2 207237b4 20723fa4
21:48:01.130 _kgspRpcGspEventPmuHalted: Received signal from GSP that PMU has halted.
21:48:01.130 Xid 154 — GPU recovery action changed from 0x0 (None) to 0x1 (PF FLR)
21:48:05.029 Reset required [NV_ERR_RESET_REQUIRED] @ gpu_user_shared_data.c:647 / :717
21:48:06.127 kgspHealthCheck_TU102: GSP-CrashCat Report
GSP task watchdog timeout @ pc:0x1b66396, partition:4#0, task:3, gfid: 0
21:48:08.614 krcWatchdog_IMPL: RC watchdog: GPU is probably locked!
21:48:31.182 Xid 45 — pid=<player>, name=showtime, channel 0x0000000f / 0x00000010
21:48:57.656 Xid 109 — channel 0x00000002, errorString CTX SWITCH TIMEOUT, Info 0x14001
Three points that I believe narrow this down:
1. The PMU halt precedes the GSP watchdog by 5 seconds. The GSP task did not fault on its
own — it was spinning waiting on a PMU that had already stopped. The primary failure is in the
power management unit, not in the graphics path.
2. Recovery is deterministic and always fails identically. The GSP-CrashCat report repeated 8 times at exactly 154-second intervals (21:48:06, 21:49:06, 21:51:40, 21:54:14, 21:56:49,
21:59:23, 22:01:58, 22:04:32) until I power-cycled the machine. Every single one reported partition:4#0, task:3 and scause:0x8000000000000005 (supervisor timer interrupt), with the
faulting PC clustered in one region: 0x1b661c8 (×3), 0x1b66396, 0x1b663ee, 0x1b6646a,
plus 0x1ba7458 and 0x109d514.
3. The PC trace shows a tight two-address loop. The captured trace alternates between 0x1b6637e and 0x109d51a for its entire depth, terminating at 0x109d45e / 0x1b66354.
This looks like a bounded poll/handshake loop with no timeout on the PMU-response path — the
task spins until the watchdog timer fires, and the retry lands in the same loop every time.
Trigger conditions — idle, not load, not thermal:
The machine had played local video via NVDEC for roughly one hour, then sat idle. The last
video was paused at 21:14:50 and the crash came at 21:48:01 — 33 minutes later, with no user
input and no GPU work in between. The player process was still alive and still holding its
decoder channels open; the subsequent Xid 45 teardown named showtime (3 channels) and multiqueue0 (8 channels, GStreamer). So the GPU spent 33 minutes attempting idle power-state
transitions with decoder contexts still allocated.
This is explicitly not the thermal variant reported elsewhere in #1045:
no thermal event of any kind in the kernel log
HW Thermal Slowdown / SW Thermal Slowdown never fired
workload before the freeze was light video decode, card was nowhere near its 250 W limit
Hardware is clean (verified after reboot): 0 correctable and 0 uncorrectable ECC errors,
no retired pages, no remapped rows, PCIe link at full 32 GT/s x16, DevSta reports no
CorrErr/NonFatalErr/FatalErr/UnsupReq, zero MCE and zero AER events in the entire boot.
The filesystem survived the hard power-off without errors. All NVreg parameters are at their
compiled-in defaults (EnableGpuFirmware=0x12, DynamicPowerManagement=3, PreserveVideoMemoryAllocations=2) — nothing is overridden on this system.
The rest of the system stayed fully alive. Scheduled jobs kept running and journald kept
writing for the entire 17 minutes between the freeze and the power-off; the kernel logged a USB
keyboard re-enumeration at 22:04:53 while the screen was already dead. Only the GPU was gone.
Because the session is Wayland with nvidia_drm.modeset=1, this also takes down every VT, so
there is no way to reach a console — a hard power-off is the only exit.
Full first GSP-CrashCat report (all 8 are structurally identical)
Arch Linux, GNOME 50 Wayland, single display on the NVIDIA GPU, nvidia_drm.modeset=1.
Play local video decoded through NVDEC (GStreamer 1.28.6 via GNOME Showtime).
Pause the video and leave the player open — decoder channels stay allocated.
Leave the machine completely idle. GNOME blanking and suspend are both disabled
(idle-delay=0, sleep-inactive-ac-type='nothing'), so this is plain idle, not DPMS or S3.
After ~30 minutes the PMU halts and the display freezes permanently.
Bug Incidence
Once so far. This is the first occurrence across 14 boots — the preceding 13 boots
(2026-08-08 through 2026-08-19, including 10 boots on this same 610.57.04 driver) logged zero Xid events. I cannot yet reproduce on demand and will report back if it recurs.
nvidia-bug-report.log.gz
Not attached — the machine has been rebooted, so a log captured now would not contain the GPU
state at failure time. The complete first GSP-CrashCat report (full RISC-V CSR/GPR state, stack
trace, PC trace, local I/O register state) is inlined above; all 8 repetitions are structurally
identical, differing only in the faulting PC. I have the full kernel journal from the failing
boot (1159 NVRM lines) and can attach it, or provide nvidia-bug-report.log.gz from the next
occurrence if that is more useful.
Things reported as ineffective in #1045, which I have therefore not tried: disabling ASPM
(already disabled on this board), persistence mode, lowering the power limit, driver downgrade
(the same chain is documented on 580, 590, 595 and 610), and reinstalling linux-firmware. NVreg_EnableGpuFirmware=0 is not an option on Blackwell.
Happy to run any instrumented driver build, enable additional GSP logging, or test a candidate
fix — the machine is a daily driver, so I will hit idle conditions constantly.
NVIDIA Open GPU Kernel Modules Version
610.57.04 (Arch Linux packages:
nvidia-open-dkms 610.57.04-1,nvidia-utils 610.57.04-1)GSP Firmware Version: 610.57.04
Please confirm this issue does not happen with the proprietary driver (of the same version)
Not tested. Blackwell (GB205) requires the open kernel modules; the Arch repositories ship
nvidia-open-dkmsonly for this GPU. I can test the proprietary.rundriver on request,but reproduction is not yet deterministic (see Bug Incidence).
Operating System and Version
Arch Linux (rolling), GNOME 50.4 on Wayland (mutter 50.4-1, gnome-shell 1:50.4-1)
Kernel Release
Linux 7.1.8-arch1-3 x86_64
Please confirm you are running a stable release kernel
Yes — stable Arch
linuxpackage, non-rc.Hardware: GPU
nvidia_drm.modeset=1.Describe the bug
The GPU's PMU halts while the system is idle, and the GSP never recovers. The desktop
freezes permanently; the rest of the system keeps running normally.
Sequence (2026-08-19, all times CEST):
Three points that I believe narrow this down:
1. The PMU halt precedes the GSP watchdog by 5 seconds. The GSP task did not fault on its
own — it was spinning waiting on a PMU that had already stopped. The primary failure is in the
power management unit, not in the graphics path.
2. Recovery is deterministic and always fails identically. The GSP-CrashCat report repeated
8 times at exactly 154-second intervals (21:48:06, 21:49:06, 21:51:40, 21:54:14, 21:56:49,
21:59:23, 22:01:58, 22:04:32) until I power-cycled the machine. Every single one reported
partition:4#0, task:3andscause:0x8000000000000005(supervisor timer interrupt), with thefaulting PC clustered in one region:
0x1b661c8(×3),0x1b66396,0x1b663ee,0x1b6646a,plus
0x1ba7458and0x109d514.3. The PC trace shows a tight two-address loop. The captured trace alternates between
0x1b6637eand0x109d51afor its entire depth, terminating at0x109d45e/0x1b66354.This looks like a bounded poll/handshake loop with no timeout on the PMU-response path — the
task spins until the watchdog timer fires, and the retry lands in the same loop every time.
Trigger conditions — idle, not load, not thermal:
The machine had played local video via NVDEC for roughly one hour, then sat idle. The last
video was paused at 21:14:50 and the crash came at 21:48:01 — 33 minutes later, with no user
input and no GPU work in between. The player process was still alive and still holding its
decoder channels open; the subsequent Xid 45 teardown named
showtime(3 channels) andmultiqueue0(8 channels, GStreamer). So the GPU spent 33 minutes attempting idle power-statetransitions with decoder contexts still allocated.
This is explicitly not the thermal variant reported elsewhere in #1045:
HW Thermal Slowdown/SW Thermal Slowdownnever firedHardware is clean (verified after reboot): 0 correctable and 0 uncorrectable ECC errors,
no retired pages, no remapped rows, PCIe link at full 32 GT/s x16,
DevStareports noCorrErr/NonFatalErr/FatalErr/UnsupReq, zero MCE and zero AER events in the entire boot.
The filesystem survived the hard power-off without errors. All
NVregparameters are at theircompiled-in defaults (
EnableGpuFirmware=0x12,DynamicPowerManagement=3,PreserveVideoMemoryAllocations=2) — nothing is overridden on this system.The rest of the system stayed fully alive. Scheduled jobs kept running and journald kept
writing for the entire 17 minutes between the freeze and the power-off; the kernel logged a USB
keyboard re-enumeration at 22:04:53 while the screen was already dead. Only the GPU was gone.
Because the session is Wayland with
nvidia_drm.modeset=1, this also takes down every VT, sothere is no way to reach a console — a hard power-off is the only exit.
Full first GSP-CrashCat report (all 8 are structurally identical)
To Reproduce
nvidia_drm.modeset=1.(
idle-delay=0,sleep-inactive-ac-type='nothing'), so this is plain idle, not DPMS or S3.Bug Incidence
Once so far. This is the first occurrence across 14 boots — the preceding 13 boots
(2026-08-08 through 2026-08-19, including 10 boots on this same 610.57.04 driver) logged
zero Xid events. I cannot yet reproduce on demand and will report back if it recurs.
nvidia-bug-report.log.gz
Not attached — the machine has been rebooted, so a log captured now would not contain the GPU
state at failure time. The complete first GSP-CrashCat report (full RISC-V CSR/GPR state, stack
trace, PC trace, local I/O register state) is inlined above; all 8 repetitions are structurally
identical, differing only in the faulting PC. I have the full kernel journal from the failing
boot (1159 NVRM lines) and can attach it, or provide
nvidia-bug-report.log.gzfrom the nextoccurrence if that is more useful.
More Info
Possibly related, all still open:
Xid 62 → 45 → 154chain on Arch + nvidia-open. Two reporters there describethe identical
partition 4#0, task 3signature. That thread now mixes at least three distinctfailure modes (thermal runaway, S4 hibernate, plain idle); this report is the plain-idle one.
__nv_drm_gem_nvkms_mapcomposes a mapping that spans BAR1→BAR3, causingmapping_reuse.c:273 NV_ERR_NO_MEMORYandkrcWatchdogGPU lock — driver 595.71.05 (open kernel modules), Resizable BAR disabled #1132 — same GPU (RTX 5070, GB205), different failure paths.Things reported as ineffective in #1045, which I have therefore not tried: disabling ASPM
(already disabled on this board), persistence mode, lowering the power limit, driver downgrade
(the same chain is documented on 580, 590, 595 and 610), and reinstalling
linux-firmware.NVreg_EnableGpuFirmware=0is not an option on Blackwell.Happy to run any instrumented driver build, enable additional GSP logging, or test a candidate
fix — the machine is a daily driver, so I will hit idle conditions constantly.