[AD102][Xorg/X11] Xid 120 GSP task exception (load access page fault) on the display path after multi-day uptime — fault follows the X server across physical cards, recurs across 570 and 580 (RTX 6000 Ada)

Updated 2026-08-03: a fourth occurrence reproduced the fault on the open kernel module (580.105.08) with vblank_sem_control=0 active for the entire boot. The forensic collector captured the GSP RPC history and exception state at the fault; the full capture is in the 2026-08-03 comment.

This issue follows the open-gpu-kernel-modules template. It is filed on the open-module tracker because the fault is in the GSP firmware, which is shared between the proprietary and open kernel modules. The fault has now reproduced on both module variants.

NVIDIA driver version

Reproduced on 570.207 (proprietary), 580.105.08 (proprietary), and 580.105.08 (open kernel module). The GSP firmware is shared between the proprietary and open kernel modules, and the fault signature is identical across both variants of 580.105.08, so this is a firmware-level fault that is not module-specific.

Operating System and Version

Ubuntu 22.04.5 LTS

Kernel Release

6.8.0-124-generic

Hardware: GPU

3x NVIDIA RTX 6000 Ada Generation (AD102, PCI 10de:26b1) in a single-node workstation. One card drives an X11 display; all three are otherwise used for CUDA compute.

Describe the bug

A reproducible NVIDIA GSP firmware task exception crashes the GPU that the X server is rendering on, after several days of uptime. The sequence is always identical:

NVRM: Xid (PCI:0000:01:00): 120, pid=2647880, name=Xorg, GSP task exception: load access page fault (cause:0xd) @ pc:0x13b7580, partition:2#0, task:3
NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (GPU Reset Required)

The kernel survives every time. Only the affected GPU's contexts die: the console freezes, nvidia-modeset then emits Error while waiting for GPU progress: 0x0000c77d every five seconds, and any CUDA work on that GPU fails. The GPU stays in "GPU Reset Required" until a reboot (nvidia-smi --gpu-reset cannot clear it while X holds the card).

This has now happened four times, and the cross-event pattern is the diagnostically interesting part:

#	Driver	Module	GPU (PCI / serial)	Fault PC	stval	Uptime at crash	Triggering process
1	570.207	proprietary	e1:00 / ...698	0x1374464	0x1f8	6.42 d	Xorg
2	570.207	proprietary	e1:00 / ...698	0x1374464	0x1f8	6.44 d	Xorg
3	580.105.08	proprietary	01:00 / ...307	0x13b7580	0x1c0	8.16 d	Xorg
4	580.105.08	open	01:00 / ...307	0x13b7580	0x1c0	7.46 d	Xorg

Key points:

• The fault follows the X server, not a physical card. Under 570.207 it hit the card at e1:00. After the X server was confined to a different card (01:00), the next two crashes moved to 01:00, a different physical GPU with a different serial. The constant across all four events is "the GPU that Xorg renders on." The card previously suspected of being defective has since run pure CUDA compute for weeks with zero faults.
• It is not fixed by a driver update or by the open kernel module. It reproduces on 570.207 and 580.105.08, and on both the proprietary and open variants of 580.105.08. The fault PC and stval differ between branches only because the GSP firmware ships with the driver; within 580.105.08 the signature is bit-identical across module variants.
• Hardware is clean on every card across every event: zero ECC errors, zero remapped rows, no MCE, no thermal or power events, empty pstore (no kernel panic).
• The decoded exception looks like a null-base pointer dereference inside the GSP display task. scause:0xd is a load page fault; stval is a tiny offset (0x1c0, previously 0x1f8), consistent with reading a struct field off a null or torn-down base pointer; the Local I/O Register State shows a 0xbadfXXXX poison sentinel (0xbadf5041 in events 1–3, 0xbadf1301 in event 4). The fault is in task:3 (the display task), reported by libos partition:2#4.
• The event-4 RPC history places the fault on a display-object teardown path. The GSP faulted while processing a CPU-to-GSP FREE of hObject=0x15070 (hClient=0xc1d01623), immediately after seven completed GSP_RM_CONTROL calls with NV0073 display-control command 0xc3700104 at ~130 µs spacing; the FREE failed with status 0x62. The full RPC history, RISC-V CSR state, stack trace, and GPR dump are in the 2026-08-03 comment.

Suspected trigger

The crash correlates with multi-day uptime on the GPU that runs the display, not with GPU load and not with a single display event. The display is idle (blanked) for almost the entire period, so the fault looks like an accumulation or eventual teardown inside the long-lived GSP display context rather than a one-off transition. The event-4 capture narrows this: the faulting operation is a FREE of a display-path object issued after a burst of NV0073 controls. The vblank-semaphore candidate is weakened because event 4 occurred with vblank_sem_control=0 active for the entire boot. Compute-only GPUs in the same chassis, which never run a display path, do not exhibit this fault even under continuous load. Related display-path GSP faults: #1028 (Xid 120 after idle/DPMS standby) and #1045.

Mitigations tested

• nvidia_modeset vblank_sem_control=0 — ineffective. Configured in /etc/modprobe.d/ and active for the entire event-4 boot; the fault recurred at 7.46 days with the identical signature.
• Confining X to a different physical GPU — relocates the fault, does not prevent it. The crash moved with the X server (events 1–2 on e1:00, events 3–4 on 01:00).
• Driver update 570.207 → 580.105.08 and proprietary → open module — no effect beyond shifting the fault PC with the firmware build.

An always-on forensic collector remains deployed. It samples per-connector DPMS state and GPU telemetry, and fires a full kernel-log and state capture the instant an Xid 120/154 appears; the event-4 capture in the comment above is its output.

To Reproduce

1. Run an X11 session (Xorg) on an RTX 6000 Ada with a display attached (real monitor or a KVM/EDID emulator; reproduced with both).
2. Allow normal display power management (DPMS / screen blank on idle).
3. Leave the system running for roughly 6 to 9 days with the usual day/night idle cycles.

The Xid 120 then fires through the Xorg display path (eventually) with no precursor.

Bug Incidence

Four occurrences to date; reproduces across two driver branches, two physical cards, and both kernel module variants. Observed uptime-to-fault band is 6.42–8.16 days.

nvidia-bug-report.log.gz

Available through a private channel on request. Held captures: a --safe-mode --extra-system-data run from the third occurrence (proprietary 580.105.08, taken while the GPU was in "GPU Reset Required"; a plain run hangs on the wedged GPU), and the forensic collector's full postmortem from the fourth occurrence (open module), including the complete RPC history and kernel log. An open-module nvidia-bug-report.log.gz from the still-wedged event-4 boot is being collected and can be supplied the same way.

Related issues

• #1028 — Xid 62/109/119/120 → 154 after idle/DPMS standby (RTX 5080, open module)
• #1045 — desktop lockup Xid 62/45 → 119 → 154, Xorg/cinnamon
• #829 — Xid 120 GSP load access page fault
• NVIDIA Developer Forums thread 364770, "Driver 580 GSP firmware crash (Xid 120/154) on RTX 3070 Mobile with HDMI display." Same Xid 120 → 154 signature on driver 580 with a connected display, on a different GPU family; the reporter notes the 535 branch was clean. That suggests the display-path GSP fault is a regression introduced in the 570/580 firmware era, which fits our data: 535 predates all of our occurrences, and the fault appears on 570.207 and 580.105.08 (both module variants).

Start with the event-4 comment containing the GSP RPC history, RISC-V CSR state, stack trace, and register dump, then compare the related display-path reports #1028 and #1045. Reproduce the X11 display workload over several days and determine whether the display-object teardown failure can be isolated and corrected; the issue provides no named source file or test.