Claude (Opus) update after new crashes (I = Claude below):
System Information
| Component |
Detail |
| GPU |
NVIDIA GeForce RTX 5090 (GB202), PCI 0000:01:00.0, power limit 600 W |
| Motherboard |
ASUS TUF GAMING B850-PLUS WIFI, BIOS 1644 (2026-03-10) |
| CPU |
AMD Ryzen 7 9850X3D (integrated Radeon Graphics present but disabled in BIOS — confirmed absent from Modules linked in) |
| OS |
Ubuntu 26.04 LTS |
| Kernel |
7.0.0-28-generic |
| Driver |
nvidia-driver-595-open, tested on both 595.71.05-0ubuntu0.26.04.1 and 595.84-0ubuntu0.26.04.1 — Xid 79 on both |
| Session |
GNOME on Wayland (GNOME Shell / mutter 50.1) with XWayland; /dev/dri/card1 (nvidia-drm) via atomic mode setting |
Symptom summary
Six crashes over eight days, all requiring a reboot to recover. Three distinct underlying signatures (console_lock hang / Xid 79 bus loss / total silence) — possibly separate issues, possibly one instability expressing itself differently depending on what the GPU was doing.
Time-to-crash after boot is highly variable: 47 min, 36 min, 23h 17min, 3min 47s, ~19 min, 7h 4min. No structure at all. This wide spread matters for anyone attempting to validate a fix here — a single crash-free day is not evidence of resolution.
Crash 1 (Jul 27, 09:16–09:20) — console_lock / command-queue hang, no Xid logged
Uptime at crash: ~47 min. Screen went black during light desktop use. Kernel log shows repeated:
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 0
nvidia-modeset: ERROR: GPU:0: Error while waiting for GPU progress: 0x0000ca7e:6 2:0:4048:4040
for ~3 minutes, preceded 60 s earlier by a single Failed to allocate NVKMS memory for GEM object. Then a hung-task chain: a console_callback workqueue thread stuck in nvEvoMakeRoom/nvkms_yield, holding the kernel console_lock, cascading into systemd-logind, gdm-session-worker, and cached_setup_font (all blocked opening a tty).
The full stack of the holding thread is notable:
console_callback -> change_console -> complete_change_console -> redraw_screen
-> fbcon_switch -> fb_pan_display -> drm_fb_helper_pan_display
-> drm_client_modeset_commit_locked -> drm_atomic_commit
-> nv_drm_atomic_commit -> ApplyModeSetConfig -> nvFlipEvo -> nvEvoMakeRoom -> nvkms_yield
i.e. a VT/console switch driving an fbcon modeset through nvidia-drm’s atomic commit path, which then blocked indefinitely in nvEvoMakeRoom (no timeout on that wait) while holding console_lock. Since the 595 series enables nvidia-drm.ko modeset=1 by default, fbcon is now routed through this path where it previously was not — potentially relevant to whether this signature is new in 595.
Crash 2 (Jul 28, 08:40:38) — Xid 79, GSP RPC failure
Uptime at crash: ~36 min. Occurred at idle (text editor only, fans not spinning, ~10 W draw with brief spikes to ~65 W).
NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.
NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (GPU Reset Required)
followed 20 s later by a burst of ~50+ _issueRpcAndWait: rpcSendMessage failed with status 0x0000000f for fn 10 / GspRmFree failed / GPU lost from the bus [NV_ERR_GPU_IS_LOST], then a kernel WARNING at nvidia_dev_put+0xcc (nv.c:5384) via nvidia_close as mutter-x11-frames was killed, then Flip event timeout on head 0.
A prior sustained compute workload at ~400 W ran without issue on this system. All four crashes occurred at idle or light/bursty load; none under sustained heavy load.
Crash 3 (Jul 29, 08:44:46) — Xid 79, with PCIe link telemetry
Uptime at crash: 23h 17min (on 595.84). Occurred while browsing Google Maps (light, intermittent rendering).
NVRM: Xid (PCI:0000:01:00): 79, pid=120583, name=nvidia-smi, GPU has fallen off the bus.
NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (GPU Reset Required)
I had a monitoring loop running (nvidia-smi --query-gpu=temperature.gpu,power.draw,power.limit,pcie.link.gen.current,pcie.link.width.current, every 5 s), hence nvidia-smi as the attached process — see crash 4 for why I don’t think that is causal. Telemetry for the 5 minutes preceding:
pcie.link.gen.current (58 samples, 5s interval): Gen1 x9, Gen2 x29, Gen5 x19
pcie.link.width.current: constant x16 throughout — no lane narrowing at any point
temperature.gpu: 37-43 C throughout
power.draw: ~10-89W, loosely correlated with the Gen5 samples
last successful sample (5s before crash): 43 C, 59.88W, Gen5, x16
The link was cycling between Gen1/Gen2 and Gen5 on nearly every sample under this bursty light load. Constant x16 width and normal temperatures argue against mechanical seating issues and thermal causes respectively.
Driver 595.84 was installed specifically to test the “suspend and resume failure with RTD3 runtime power management” fix in that release’s changelog. It did not resolve the issue — though note this boot was also the longest crash-free run recorded (23 h), so I cannot conclude 595.84 had no effect either way.
Crash 4 (Jul 29, 08:50:51) — Xid 79, 3min 47s after a warm reboot
NVRM: Xid (PCI:0000:01:00): 79, pid=1935, name=nvidia-modeset/, GPU has fallen off the bus.
NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (GPU Reset Required)
No monitoring script was running this time, and the attached process was the kernel’s own nvidia-modeset/ worker. This weakens the idea that my polling loop was a trigger in crash 3 — the pid/name field appears to just reflect whichever client last touched the resource manager.
Caveat: this followed a warm reboot after crash 3. Given Xid 154 explicitly reports “GPU Reset Required”, and other reports in this forum state only a full cold power cycle recovers the card, crash 4 may not be an independent data point — the GPU may never have been properly reset. I’m treating warm-reboot-after-Xid-79 as contaminated going forward.
Userspace signature: identical NULL dereference in libnvidia-glcore across two driver versions
Two OpenGL client segfaults are logged since Jul 24, and both coincide with GPU crashes:
Jul 27 09:17:11 kernel: ptyxis[11941]: segfault at f0 ip 000076604a62c60e sp 00007ffdb4b46080 error 4 in libnvidia-glcore.so.595.71.05[e2c60e,766049c00000+c00000] likely on CPU 0
Jul 29 08:50:56 kernel: ptyxis[8396]: segfault at f0 ip 00007f20de02c94e sp 00007ffe85172c60 error 4 in libnvidia-glcore.so.595.84[e2c94e,7f20dd600000+c00000] likely on CPU 1
Both are error 4 (userspace read of a non-present page) at fault address 0xf0 — i.e. a NULL pointer dereference reading a field at offset 240. The reported file offsets are 0xE2C60E (595.71.05) and 0xE2C94E (595.84) — 832 bytes apart across two separate builds of the library, so this is the same code path in both cases, not two unrelated faults.
Ordering differs between the two occurrences:
- Jul 27: the segfault at 09:17:11 came after the
Failed to allocate NVKMS memory for GEM object at 09:16:10, but before the first Flip event timeout at 09:17:18. (update-notifier-crash.service failing at 09:17:14-15 is apport handling this very segfault.)
- Jul 29: the segfault at 08:50:56 came 5s after Xid 79 at 08:50:51 — clearly a consequence there.
So the segfault is a consequence in both cases, but on Jul 27 a consequence of an allocation failure rather than of a bus disconnect. Either way, libnvidia-glcore appears to NULL-deref rather than returning an error when GPU resources become unavailable — that looks like an independently fixable defect regardless of the root cause of the GPU going away.
Core dump analysis of the Jul 29 ptyxis crash (gdb /usr/bin/ptyxis CoreDump) confirms the mechanism:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f20de02c94e in ??? () at /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.595.84
#1 0x00007f20ddf2b3ad in ??? () at /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.595.84
#2-#15 in ??? () at /usr/lib/x86_64-linux-gnu/libgtk-4.so.1 (GSK renderer internals)
#16 0x00007f21201df5ab in gsk_renderer_render () at /usr/lib/x86_64-linux-gnu/libgtk-4.so.1
#17-#19 in ??? () at /usr/lib/x86_64-linux-gnu/libgtk-4.so.1
#20-#26 g_signal_emit / g_signal_emit_valist (libgobject-2.0)
#27-#31 g_main_context_iteration (libglib-2.0)
#32 g_application_run (libgio-2.0)
#34-#36 __libc_start_main / main
rdi 0x0 0
rsi 0x1 1
Two points from this:
-
rdi = 0x0 — the first argument register is NULL at the fault. Combined with segfault at f0, the function was called with a NULL pointer and dereferenced a field 240 bytes into the structure it should have pointed to. (Caveat: registers reflect frame 0’s state and could in principle have been reused, but with fault address 0xf0 the inference seems sound.)
-
Frames 0 and 1 are both inside libnvidia-glcore. The NULL was passed down from another function within the driver library itself, not supplied by GTK. This looks like an unchecked NULL return propagating internally after the GL context was lost — not API misuse by the client.
The crash occurred inside gsk_renderer_render() from the ordinary GTK main loop, i.e. during routine frame rendering, ~5 s after the GPU went away — not during teardown or initialization.
Second userspace signature: libnvidia-eglcore calls abort() — identical code path in two different processes, five days apart
Two separate compositor-side processes have aborted from inside libnvidia-eglcore after the GPU went away. Both produced usable backtraces.
Xwayland, Jul 29 (crash 3) — from Xwayland’s own backtrace printer, SIGABRT:
(EE) 2-5: libc.so.6 (pthread_kill / gsignal / abort)
(EE) 6: libnvidia-eglcore.so.595.84 (0x77218a200000+0x2bd20e) <-- caller of abort()
(EE) 7-18: libnvidia-eglcore.so.595.84 (+0xaf7def, +0xaf8389, +0xa5cb42, +0xa5d750, ...)
(EE) 19-20: libEGL_nvidia.so.0 (+0xaa198, +0xa8c28)
(EE) 23-30: /usr/bin/Xwayland (startup path from main -> EGL init)
Fatal server error: (EE) Caught signal 6 (Aborted). Server aborting
gnome-shell, Aug 3 (crash 6) — from the apport core dump, SignalName: SIGABRT:
#10 __GI___abort ()
#11 ??? () at libnvidia-eglcore.so.595.84 (0x71cbbdcbd20e)
#12-#23 ??? () at libnvidia-eglcore.so.595.84
#24-#25 ??? () at libmutter-cogl-18.so.0
#26 cogl_texture_allocate () at libmutter-cogl-18.so.0
#27 ??? () at libmutter-18.so.0
#31-#33 wl_event_loop_dispatch () at libwayland-server.so.0
#34-#37 g_main_loop_run () at libglib-2.0.so.0
#38 meta_context_run_main_loop () at libmutter-18.so.0
Resolving the gnome-shell frames against an inferred library base of 0x71cbbda00000 gives four consecutive frames identical to the Xwayland abort:
| Frame |
Xwayland (Jul 29) |
gnome-shell (Aug 3) |
caller of abort() |
+0x2bd20e |
+0x2bd20e |
| next |
+0xaf7def |
+0xaf7def |
| next |
+0xaf8389 |
+0xaf8389 |
| next |
+0xa5cb42 |
+0xa5cb42 |
| next |
+0xa5d750 |
+0xa5d89b |
(The base address is inferred by subtraction, but four exact matches make the inference safe. The fifth frame differs by 331 bytes — probably two call sites within the same function.)
The two reached that path from very different places: Xwayland during EGL initialization at session restart, gnome-shell during routine texture allocation in the main loop, servicing a Wayland client buffer commit via cogl_texture_allocate(). So the abort is not confined to an init-time corner case.
Note that gnome-shell is the Wayland compositor here. abort() called from inside a library terminates the process with no opportunity for error handling, which takes down the whole graphical session — this is the direct cause of the black screen, not a downstream casualty. A GTK application can at least be steered away from the GL path (GSK_RENDERER=cairo); a compositor has no such option.
Together with the glcore segfault, the two NVIDIA userspace libraries fail in two different ways and neither returns an error to the caller:
| Library |
API |
Behaviour when the GPU disappears |
libnvidia-glcore |
OpenGL |
NULL pointer dereference → SIGSEGV |
libnvidia-eglcore |
EGL |
explicit abort() → SIGABRT |
Sequence at crash 3 (Jul 29):
08:44:46 Xid 79 (GPU has fallen off the bus) + nv_drm_semsurf_wait_fence_work_cb error
08:44:47 gnome-shell (pid 6478) crashes with signal 6
-> GDM restarts the session
08:44:53 new Xwayland (pid 9074) aborts inside libnvidia-eglcore during EGL init
08:44:57 Flip event timeout on head 0 (repeats)
08:44:58 systemd SIGKILLs mutter-x11-frames
08:45:03 WARNING nvidia/nv.c:5384 at nvidia_dev_put+0xcc/0xd0, repeated on CPUs 2/9/10/11
for both mutter-x11-frames and Xwayland
08:45:03 gsd-xsettings: XIO fatal IO error 4 on X server
The repeated nvidia_dev_put warnings across many CPUs and many processes look like a refcount imbalance in the kernel module when clients release GPU handles for a device that no longer exists — a third defect in the same family. At crash 6 these fired for at least a dozen distinct processes (code, qgis, signal-desktop, ibus-x11, Xwayland, mutter-x11-frames, gmain, several Vulkan worker threads) across CPUs 0-12.
Crash 6 (Aug 3, 13:42:44) — Xid 79 with SysRq diagnostics: the kernel stays fully alive
Uptime at crash: 7h 4min (boot 06:38:10). Light desktop use. First kernel evidence is the Xid itself, with a kernel-side stack showing where the loss was detected:
NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.
NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (GPU Reset Required)
os_dump_stack -> _kgspRpcRecvPoll -> _issueRpcAndWait -> rpcRmApiControl_GSP
-> RmGssLegacyRpcCmd -> _nv04ControlWithSecInfo -> RmIoctl -> rm_ioctl
-> nvidia_unlocked_ioctl
i.e. detected while polling for a GSP RPC reply that never arrived, on a userspace ioctl path.
With full SysRq enabled, all three commands executed successfully ~30 s later:
13:43:15 sysrq: Show Blocked State
13:43:22 sysrq: Emergency Sync
13:43:22 Emergency Sync complete
13:43:27 sysrq: Emergency Remount R/O
13:43:27 EXT4-fs (nvme0n1p5): re-mounted ... ro
Filesystem sync completed and remount succeeded, and SysRq+B then rebooted cleanly (journalctl --list-boots shows this boot ending 13:43:27, the next starting 13:43:52). This is not a hard lockup — the kernel was scheduling, running filesystem code and writing to disk the whole time the screen was black. The failure is confined to the graphics stack. /sys/fs/pstore/ is empty, consistent with no panic.
The Show Blocked State output listed only two tasks:
task:nvidia-modeset/ state:D pid:2036
__down -> down -> nvkms_kthread_q_callback [nvidia_modeset] -> _main_loop
task:kworker/1:2 state:D pid:43997 Workqueue: events console_callback
__down -> down -> console_lock -> console_callback
This is important for interpreting crash 1. Crash 6 exhibits both signatures at once: Xid 79 at 13:42:44, and a console_callback worker blocked on console_lock at 13:43:15. I had been treating the crash-1 console_lock hang as possibly a separate bug from the Xid 79 bus-loss crashes; this strongly suggests they are the same cascade caught at different stages. Crash 1 most likely also began with a bus loss that was never logged before the machine froze — supported by Failed to allocate NVKMS memory for GEM object appearing in both.
The blocked-task list here is much shorter than crash 1’s (which had five tasks including systemd-logind and gdm-session-worker) simply because SysRq+W was pressed 31s after the Xid, whereas crash 1’s hung-task warnings only fired at the kernel’s 122s threshold, by which point the chain had spread.
Note that neither blocked task shows the holder of console_lock — it is presumably runnable rather than in D state, so it does not appear in a W dump. SysRq+L (backtrace all active CPUs) would be needed to identify it.
_usr_bin_Xwayland.1000.crash (10MB, Jul 29 08:44 = crash 3) and _usr_bin_ptyxis.1000.crash (13MB, Jul 29 08:50 = crash 4). That apport successfully wrote 10-13MB to disk means the kernel survived crashes 3 and 4 — only the GPU and the session died. Contrast with crash 1 (SSH unreachable) and crash 5 (zero-byte crash file, journal truncated mid-stream): there appear to be at least three distinct severity levels here.
Crash 5 (Jul 31, ~08:07) — total silence, no Xid, no error messages at all
Uptime at crash: ~19 min (boot 07:47:47). Occurred during ordinary desktop use; screen went black. Disabling GNOME screen blanking and display power management beforehand did not prevent it.
Both journalctl -b -1 -k and the full journalctl -b -1 end at 08:04:17 on an unrelated audit line, with no NVIDIA errors, no Xid, no flip timeouts, no hung-task warnings of any kind. A zero-byte /var/crash/_usr_bin_gnome-shell.1000.crash timestamped 08:07 suggests gnome-shell crashed and apport began a report that was never written — placing the freeze at ~08:07 and implying the system stopped hard enough that neither apport nor journald could flush to disk.
/sys/fs/pstore/ is empty, so no kernel panic was recorded. kdump is loaded but would not fire without a panic. I have since enabled full SysRq to distinguish “kernel alive, GPU dead” from a true hard lockup on the next occurrence.
Variables ruled out
- Integrated AMD graphics — disabled in BIOS;
amdgpu confirmed absent from the module list at crash time; crashes continued.
- Display output path — multiple DisplayPort outputs tested from both GPU and (before disabling) motherboard; same result on all.
- Driver version — 595.71.05 and 595.84 both affected.
- Thermal — 37-43 C at crash.
- Screen blanking / display power management — disabled in GNOME; crash 5 occurred anyway.
- PCIe lane width degradation — constant x16.
- Sustained high load — ~400 W compute workload ran clean; crashes occur at idle/light load only.
Not yet tested
- X11 session instead of Wayland
nvidia-drm.fbdev=0 (targets crash 1’s fbcon path specifically)- BIOS/AGESA version change (BIOS 1644 currently; other threads here report AGESA version as decisive in both directions)
pcie_aspm=off- CPU C-state limiting (
processor.max_cstate=1 / BIOS Global C-State Control)
nvidia.NVreg_EnableRuntimePM=0
Working hypothesis — and one hypothesis now falsified
I previously suspected frequent PCIe link power-state transitions were opening a window for a GSP heartbeat miss, based on crash 3’s telemetry. Crash 6 falsifies this. Comparing the same telemetry window:
|
Gen1 |
Gen2 |
Gen5 |
| 60 samples before crash 3 (Jul 29) |
9 |
32 |
19 |
| 100 samples before crash 6 (Aug 3) |
98 |
2 |
0 |
Crash 3 was preceded by the link switching on nearly every sample; crash 6 by half an hour of a completely static Gen1 link. Same outcome, opposite conditions. Frequent link retraining cannot be the common factor.
Also worth recording: a ~367W compute workload ran earlier the same day without incident, and the crash came at ~16W. Load is not the trigger either. And crash 6 at 13:42 breaks the 08:40-09:20 clustering I had noted across the first five crashes — that was an artifact of too few data points.
What remains consistent across all six: the GPU stops responding on the GSP RPC channel while idle or lightly loaded, at wildly varying uptimes, with no PCIe AER errors, normal temperatures and no lane-width degradation beforehand.
Separately from the root cause, the driver’s failure handling looks independently fixable: nvEvoMakeRoom waits without a timeout while console_lock is held (escalating a display fault into a system-wide hang — SSH was unreachable at crash 1), libnvidia-glcore NULL-derefs, libnvidia-eglcore calls abort(), and nvidia_dev_put warns on every client that closes a handle afterwards.