RTX 5070 Ti (Blackwell) — Xid 79 / Xid 119 cascade / silent idle hangs on 580.159.03 open module

Graphics / Linux Linux
1

# Bug report — RTX 5070 Ti intermittent crashes (Xid 79, Xid 119 cascade, silent hangs)

## TL;DR

System76 Thelio Mira (Ryzen 9 9950X + RTX 5070 Ti, Blackwell GB203) on Pop!_OS 22.04 with NVIDIA 580.x open kernel module. **Intermittent crashes since the machine was new (~9–10 months).** Three distinct failure signatures observed; all reproducible across driver bumps 580.82 → 580.119 → 580.126 → 580.159 and across kernels 6.12 → 6.16 → 6.17. Power-management workarounds (DPM=0, persistence mode, `pcie_aspm=off`) have been tried in combination and **do not prevent the workload-triggered fall-off-the-bus mode**.

Detailed kernel logs are available only from **2026-05-17 onward** due to log rotation; earlier crashes are observed by the user but not captured.

## System

| | |

|—|—|

| Vendor / model | System76 Thelio Mira (r4) |

| BIOS | American Megatrends 4.10.SP01, 2026-02-23 |

| CPU | AMD Ryzen 9 9950X (16-core) |

| GPU | NVIDIA GeForce RTX 5070 Ti (Blackwell, GB203-A) — PCI ID `10de:2c05`, subsystem `1458:41a8` (Gigabyte) |

| VBIOS | 98.03.3B.80.C6 |

| GPU memory | 16 GB |

| Display path | **AMD iGPU drives the display.** NVIDIA card is idle except for compute. |

| OS | Pop!_OS 22.04 |

| Kernel (current) | 6.17.9-76061709-generic (System76 build, kernel-config `202511241048`) |

| NVIDIA driver (current) | 580.159.03 (open kernel module) |

| OS install date | 2025-08-09 (rootfs / machine-id birth) |

## Driver / kernel timeline (apt history)

Drivers used on this machine — all 580-series so far have been the **open** kernel module:

| Date | NVIDIA driver | Kernel |

|—|—|—|

| 2025-07-02 | nvidia-driver-570-open 570.153.02 | linux-system76 6.12.10 |

| 2025-08-09 | (same driver) | 6.12.10 (rebuild) |

| 2025-09-10 | (same driver) | **6.16.3** (major bump) |

| 2025-09-22 / 09-25 | 570.153.02 (rebuilds) | 6.16.3 (rebuilds) |

| **2025-10-08** | **transition to 580.82.09-open** | 6.16.3 |

| 2025-10-10 / 10-11 | 580.82.09 (rebuilds) | 6.16.3 |

| 2025-10-21 | — | 6.16.3 (rebuild) |

| 2025-11-11 | — | **6.17.4** |

| 2026-01-07 | — | **6.17.9** |

| 2026-01-15 | **580.119.02** | 6.17.9 |

| 2026-03-19 | **580.126.18** | 6.17.9 |

| 2026-05-04 | **580.159.03** | 6.17.9 (rebuild) |

| 2026-05-17 | 580.159.03 | 6.17.9 (rebuild) |

Crashes have been intermittent across **every** combination listed above per the user’s recollection. The recent (May 17–18) cluster captured in logs occurred on 580.159.03 + 6.17.9.

## Failure signatures

Three distinct kernel-log signatures observed:

### A. Silent hang at idle

- No Xid logged.

- Journal truncates mid-stream; no errors, no panic, no NVRM message.

- Recovery: hard power-cycle required.

- Triggered: with the machine sitting idle on the desktop. The display is on the AMD iGPU, so the NVIDIA card is genuinely idle when this hits.

- Captured: 2026-05-17 16:56 boot (52 min, the original case); 2026-05-18 11:22 boot (23 min, **with `NVreg_DynamicPowerManagement=0` already in effect**).

- Log: `~/nvidia-crash-2026-05-18-b-1-silent.log`

### B. Xid 79 — “GPU has fallen off the bus”

- Two sub-triggers observed:

1. **`nvidia-smi` polling** while otherwise idle (2026-05-17 16:55, 2026-05-18 09:47 boot).

2. **Sustained `ollama` LLM-inference load** (~4–5 `/api/chat` requests per second, ~5 min into boot, no preceding GSP timeout — 2026-05-18 12:19 boot, **with DPM=0 + persistence mode + `pcie_aspm=off` all confirmed active**).

- After Xid 79: cascade of `_threadNodeCheckTimeout: API_GPU_ATTACHED_SANITY_CHECK failed`, then ~3900 `rpcSendMessage failed with status 0x0000000f` GSP RPC errors during teardown.

- Recovery: hard power-cycle required.

- Log: `~/nvidia-crash-2026-05-18-b-2.log`

### C. Xid 119 → 110 → 79 cascade under load

- Xid 119 (GSP RPC timeout) → Xid 154 (recovery action / reset required) → `SEC_FAULT: _CLOCK_GPC_FMON` → `SEC_FAULT: _DEVICE_LOCKDOWN` → Xid 79.

- `uvm encountered global fatal error 0x60, requiring os reboot to recover`.

- Triggered: `ollama` inference workload (2026-05-18 11:02 boot, 19 min uptime).

- Captured: `~/nvidia-crash-2026-05-18-b-1.log`

## Boot history (captured period only)

The system has had intermittent crashes since the machine was new (the user reports issues going back ~9–10 months). Kernel logs prior to 2026-03-22 are gone due to rotation; `journalctl --list-boots` only retains entries from 2026-03-27 onward. The boots below are the period for which detailed evidence exists.

| Boot started | Duration | Outcome |

|—|—|—|

| 2026-05-04 11:21 | 41 min | clean shutdown |

| 2026-05-17 16:27 | 27 min | Xid 79 (triggered by `nvidia-smi`) |

| 2026-05-17 16:56 | 52 min | **silent hang** at idle |

| 2026-05-17 18:33 | 15 h | Xid 79 at 04:05 then 5+ h of modeset errors |

| 2026-05-18 09:45 | 1 min | clean reboot |

| 2026-05-18 09:47 | 1 h 13 m | Xid 119 GSP timeout + kernel stack trace |

| 2026-05-18 11:02 | 19 min | Xid 119 → 110 → 79 cascade under ollama — first crash with DPM=0 in effect |

| 2026-05-18 11:22 | 23 min | **silent hang at idle** with DPM=0 in effect |

| 2026-05-18 11:47 | 18 min | clean reboot (persistence-mode override applied) |

| 2026-05-18 12:07 | 12 min | clean reboot (ASPM config staged) |

| 2026-05-18 12:19 | 5 min | **Xid 79 under ollama load** — first all-fixes boot (DPM=0 + persistence + `pcie_aspm=off`); ASPM disabled at the kernel level did not prevent fall-off-the-bus |

| 2026-05-18 12:25 | 1 min | clean reboot |

| 2026-05-18 12:27 | current | second all-fixes boot |

## Mitigations tried (and current results)

| Mitigation | Applied | Verified active | Effect on workload-triggered Xid 79 | Effect on silent idle hang |

|—|—|—|—|—|

| `NVreg_DynamicPowerManagement=0` | 2026-05-18 | `DynamicPowerManagement: 0` in `/proc/driver/nvidia/params` | did NOT prevent | did NOT prevent (recurred 11:22 boot) |

| Persistence mode (drop-in override to remove `–no-persistence-mode` from `nvidia-persistenced.service`) | 2026-05-18 12:07 | `nvidia-smi -q` reports `Persistence Mode: Enabled` | did NOT prevent | not retested |

| `pcie_aspm=off` kernel cmdline | 2026-05-18 12:19 boot | kernel logs `PCIe ASPM is disabled`; `/proc/cmdline` confirms | did NOT prevent (crashed 5 min in on first such boot) | not retested |

Power-management explanations are therefore **exhausted** for the workload-triggered fall-off-the-bus mode. The silent-idle-hang mode has not yet been retested with all three mitigations active *while idle*, because the 12:19 boot died under load before reaching idle.

## Representative log excerpt — 2026-05-18 12:19 boot, Xid 79 under ollama load

Boot started with all three mitigations active. Kernel confirms `PCIe ASPM is disabled` and ollama begins serving requests immediately. The kernel log shows zero NVIDIA messages between driver load (12:19:23) and the failure (12:24:38) — i.e., no GSP warning, no AER, no degraded link — and then the GPU vanishes mid-request:

```

May 18 12:24:37 pop-os ollama[2149]: [GIN] 2026/05/18 - 12:24:37 | 200 | 240ms | POST “/api/chat”

May 18 12:24:38 pop-os ollama[2149]: [GIN] 2026/05/18 - 12:24:38 | 200 | 324ms | POST “/api/chat”

May 18 12:24:38 pop-os kernel: NVRM: GPU at PCI:0000:01:00: GPU-4ca99914-…

May 18 12:24:38 pop-os kernel: NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.

May 18 12:24:38 pop-os kernel: NVRM: GPU 0000:01:00.0: GPU has fallen off the bus.

May 18 12:24:38 pop-os kernel: NVRM: kgspRcAndNotifyAllChannels_IMPL: RC all channels for critical error 79.

May 18 12:24:38 pop-os kernel: NVRM: _threadNodeCheckTimeout: API_GPU_ATTACHED_SANITY_CHECK failed!

… (~3900 rpcSendMessage failed status 0x0000000f errors during teardown) …

May 18 12:24:44 pop-os kernel: nvidia-modeset: ERROR: GPU:0: Error while waiting for GPU progress

May 18 12:24:44 pop-os kernel: fbcon: Taking over console

```

Full log: `~/nvidia-crash-2026-05-18-b-2.log`

## What I would like to understand

1. Is this a known Blackwell + 580.x open-kernel-module GSP/firmware issue, and is there an action (newer driver, firmware update, config) that has resolved it for others?

2. Is the **`nvidia-smi`-triggered Xid 79** observed on this hardware a known stale-RM-state issue that persistence mode should resolve? (It did not in our tests.)

3. Are there diagnostics — beyond `nvidia-bug-report.sh` — that would help distinguish a hardware issue (PCIe signal integrity, PSU transient response) from a firmware/driver issue? Specifically: a way to capture PCIe AER state at the moment the link drops, since none is currently logged before Xid 79.

## Attachments

- `nvidia-bug-report.log.gz` (output of `sudo nvidia-bug-report.sh` from current boot).

- `nvidia-crash-2026-05-18-b-1.log.gz` — Xid 119 → 110 → 79 cascade under ollama.

- `nvidia-crash-2026-05-18-b-1-silent.log.gz` — silent idle hang.

- `nvidia-crash-2026-05-18-b-2.log.gz` — Xid 79 under ollama with all three mitigations active.

## Reproduction notes for triage

- Idle silent hang: leave machine idle on GNOME/X11 desktop; typically hits within ~25–55 min. No `nvidia-smi` poking required.

- Xid 79 (polling): run `watch -n1 nvidia-smi`; reproduces in tens of minutes on a fresh boot.

- Xid 79 (load): run `ollama serve` and a tight loop of `/api/chat` requests; reproduced in 5 min on 2026-05-18 12:19 boot.

- Xid 119 cascade: same trigger as above; appears to be the “slow death” variant where GSP times out before the link drops.

nvidia-crash-2026-05-18-b-2.log.gz (27.2 KB)

nvidia-crash-2026-05-18-b-1-silent.log.gz (22.7 KB)

nvidia-crash-2026-05-18-b-1.log.gz (33.4 KB)

nvidia-bug-report.log.gz (498.6 KB)

2

RTX 5070 Ti — Xid 79 “GPU has fallen off the bus” triggered by browser open with concurrent Ollama CUDA context (Fedora, driver 610.43.03 open kernel module)

Summary

Two independent Xid 79 crashes on an RTX 5070 Ti (desktop, ~2 months old) running Fedora with the NVIDIA open kernel module 610.43.03. Both crashes happened within ~60–90 seconds of opening a web browser while Ollama (running as a systemd service, autostarted at boot) had a model already resident in VRAM via CUDA. This matches the pattern described in the existing thread “RTX 5070 Ti (Blackwell) — Xid 79 / Xid 119 cascade / silent idle hangs”, specifically sub-trigger B (“sustained ollama LLM-inference load”). Posting this as a +1 with a slightly different trigger shape (browser launch against a pre-loaded CUDA context, rather than sustained inference load) in case it’s useful for narrowing down the root cause.

System Configuration

Component Value
GPU NVIDIA GeForce RTX 5070 Ti
Driver 610.43.03, Open Kernel Module (built 2026-06-30)
OS Fedora (Fedora 44 packages, per libdrm-2.4.134-1.fc44)
Desktop / Compositor KDE Plasma, kwin_wayland (Wayland session)
Displays Samsung LS22D300G (HDMI-1) + Asustek VA27AQ (DP-0), dual-monitor
Relevant background service ollama (systemd service, enabled, autostarts at boot; CUDA compute backend, libdirs=ollama,cuda_v13, driver=13.3)
System age ~2 months, desktop PC, no overclocking
Kernel version 7.1.3-201.fc44.x86_64
CPU / Motherboard / PSU Ryzen 7 7700 / MSI B850 MAG B850 TOMAHAWK MAX WIFI / MSI MAG A1000GLS PCIE5
Power mitigations tested Not yet applied (no DPM=0 / persistence mode / ASPM=off tested yet — planning to test after ruling out the Ollama correlation)

Timeline — Incident 1 (2026-07-23, ~11:11)

  • Browser open, playing a YouTube video (static album-cover thumbnail, effectively no motion/video decode load).
  • Only a single relevant line was captured before the reboot wiped the previous boot’s dmesg buffer:
NVRM: _issueRpcAndWait: rpcSendMessage failed with status 0x0000000f for fn 76 sequence 24670!
  • System black-screened and required a manual reboot. No further detail available for this boot (journalctl for the previous boot ID was not preserved / rotated out before it was pulled).

Timeline — Incident 2 (2026-07-26, ~12:00–12:05) — full log captured

12:00:59  Driver 610.43.03 loads at boot (NVRM, nvidia-modeset)
12:01:01  nvidia-powerd fails to start: "ERROR! UnSupported CPU: 2." / "ERROR! UnSupported System."
12:01:06  coolercontrold detects GPU (RTX 5070 Ti) fine, reads sensors/fans normally
12:01:25  ollama[1671]: inference compute backend loaded — CUDA0, compute=12.0, driver=13.3,
          total=15.5 GiB, available=15.0 GiB VRAM  →  model resident in VRAM via CUDA context
12:01:53  kwin_wayland: compositor starts (drm backend)
12:02:01  nvidia-settings autostart launches
--- ~24 seconds after nvidia-settings launch / ~60s after ollama loaded the model ---
12:02:25  NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.
12:02:25  NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (PF FLR)
12:02:26  kwin_wayland: "Pageflip timed out! This is a bug in the nvidia-drm kernel driver" (repeats)
12:02:28  [drm:__nv_drm_semsurf_wait_fence_work_cb] *ERROR* Failed to register auto-value-update
          on pre-wait value for sync FD semaphore surface
12:02:29  Multiple WARNING traces at nvidia/nv.c:5333 (nvidia_dev_put) and nv.c:5308 (nvidia_dev_get),
          across kwin_wayland, Xwayland, and WaylandEventThr threads
12:02:29  [drm] Failed to allocate NVKMS video memory for GEM object, trying to fall back to sysmem
12:02:37  nvidia-modeset: "The requested configuration of display devices (Samsung LS22D300G
          (HDMI-1), Asustek Computer Inc VA27AQ (DP-0)) is not supported on this GPU." (repeats ~11x)
12:02:37  nvidia-modeset: "Failed to query display engine channel state: 0x0000ca7d:0:0:0x0000000f"
          and 0x0000ca7e channels 0–7, repeated in bursts
12:02:44 → 12:05:07  Same "Failed to query display engine channel state: 0x0000ca7e:6:0:0x0000000f"
          error repeats every ~10 seconds for the remaining ~2.5 minutes of the boot — GPU never
          recovers on its own

The boot ends at 12:05:16 (per journalctl --list-boots), consistent with a manual hard reset since the display engine was stuck in the retry loop above and never recovered.

Note: unlike sub-case B/C in the referenced thread, this incident did not show a nvidia_uvm fatal error (uvm encountered global fatal error 0x60...) or SEC_FAULT lines — the failure stayed contained to Xid 79/154 plus the display-engine channel-state retry loop. nvidia_uvm(OE) appears in the loaded-modules list of the WARNING traces, but no UVM error string is present in the log.

Trigger pattern observed

Both incidents share the same shape:

  1. Ollama service is running with a model loaded in VRAM (compute/CUDA context active), started automatically at boot.
  2. A web browser is opened/foregrounded, requiring the display/graphics engine to render + composite (Wayland/KDE).
  3. Within roughly 60–90 seconds of that transition, Xid 79 fires, followed by an unrecoverable display-engine error loop requiring a manual reboot.

This looks consistent with a context-switch issue between the GPU’s compute engine (CUDA, held open by Ollama) and its display/graphics engine (triggered by the browser), rather than being tied to sustained load, temperature, or video decode specifically — in Incident 1 the “video” was a static thumbnail, not an actively decoding stream.

Next steps on my end

  • Disabling the Ollama systemd autostart (systemctl disable ollama) and using the browser normally for a period, to confirm whether removing the concurrent CUDA context prevents the crash.
  • Will report back with results and can also apply the DPM=0 / persistence-mode / pcie_aspm=off mitigations mentioned in the referenced thread if the Ollama correlation holds, to see if they help despite showing no effect in that report.

Attachments

  • Full journalctl export for Incident 2 boot available on request (crash_log.txt, ~360 lines, includes full stack traces for the nvidia_dev_put/nvidia_dev_get WARNINGs and repeated display-engine channel-state errors, trimmed here for readability).

Happy to provide nvidia-bug-report.sh output or additional journalctl -b -1 context if useful.

crash_log.txt (61.7 KB)

3

Update: ruled out Ollama and browser hardware video decode — still only reproduces with Chromium + YouTube, not on Windows 11 with the same hardware

Follow-up to my post above. Since then I’ve had a third Xid 79 crash, and ran a few tests to narrow down the trigger. Posting the results in case they help isolate this.

Incident 3 (2026-07-30, ~23:07)

  • ollama was disabled (systemctl disable + confirmed not running this boot — no ollama process anywhere in the log) — first incident with the CUDA/compute context completely out of the picture.
  • Chromium, hardware video acceleration already disabled in browser settings (chrome://settings → hardware acceleration off) since before this incident.
  • Same Xid 79 → Xid 154 → display-engine channel-state retry loop signature as incidents 1 and 2, plus one new line this time:
23:07:38  NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.
23:07:38  NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (PF FLR)
23:07:38  nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x0000ca7e:6/4/0/2:0:0x0000000f (repeated)
23:07:38  nvidia-modeset: ERROR: GPU:0: DP-0: Failed to disable DisplayPort audio stream-3
  • Once again: browser open, playing a YouTube video, nothing else unusual running.

This rules out Ollama / concurrent CUDA context as the (sole) trigger — it was not running at all in this boot and the crash happened anyway.

Tests performed to isolate the trigger

Since sustained heavy load (AI inference, Blender rendering) had never once caused a crash, while light/short YouTube sessions had caused 3, I tried to reproduce it with synthetic load/transition patterns instead of just “wait and see”:

  1. Sustained polling to force idle↔active power-state transitions (watch -n 1 nvidia-smi) while browsing normally, no YouTube.
  2. YouTube video (2K) playing concurrently with the GPU already under sustained heavy load — specifically rendered the Blender “The Junk Shop” demo scene (Cycles, GPU render) at the same time as the YouTube playback, to see if keeping the GPU in a stable high-power state (instead of idle) would prevent the transition-related crash.
  3. Result: no crash reproduced in either case. Rendering + YouTube playback simultaneously ran fine the whole time.

This is a useful negative result: it suggests the trigger isn’t simply “any GPU power-state transition” or “video decode load” in isolation — under sustained load it’s stable, and so far it has only failed during specific, unforced everyday Chromium+YouTube sessions (not reproduced on demand yet).

Doesn’t happen on Windows 11

Same physical hardware (same PC, same GPU, no changes) has not shown this issue running Windows 11. This points fairly strongly at something in the Linux driver/firmware (GSP) stack specifically, rather than a hardware fault — for whatever that’s worth for others hitting this on dual-boot systems trying to decide whether it’s worth an RMA (in my case, hard to justify one anyway, since a shop would very likely just test under Windows or under sustained load and find nothing wrong).

What might differ about YouTube specifically vs. local video playback

Still trying to isolate this further. Things on my list to test that differ between a YouTube session and, e.g., a local file played in the same browser:

  • Widevine DRM initialization
  • Adaptive bitrate switching / stream renegotiation
  • Ad insertion (repeated creation/teardown of the video decode context)

Haven’t nailed down which of these (if any) matters yet — will update if a controlled test isolates it.

Plan going forward

  • Running Windows 11 for an extended period (~10 days) as a control, to further confirm this doesn’t happen there under normal use.
  • Avoiding YouTube specifically in Chromium on Linux in the meantime as a practical workaround, since everything else (AI workloads, Blender, general browsing without YouTube) has been stable.

Happy to run any specific test someone following this thread suggests — at this point sustained load doesn’t trigger it, but normal everyday YouTube browsing does, fairly reliably (3/3 sessions where I happened to be capturing logs).

crash_log_30-07.txt (5.2 KB)

4

Update 2: 4th occurrence — crash consistently tied to the first ~20 minutes after boot, full GSP RPC stack trace captured, audio channel survives the video hang

Another data point since my last update, plus a pattern that’s starting to look very consistent across all 4 occurrences so far.

Incident 4 (2026-07-31, ~11:19)

  • Driver loaded at boot: 10:59:07. Browser + YouTube opened almost immediately after login.
  • Crash at 11:19:12 — ~20 minutes after boot, the longest it’s held up so far, but still within the same early post-boot window as the other 3 incidents (see timing table below).
  • Same Xid 79 → Xid 154 → display-engine channel-state retry signature as before, but this time the kernel also emitted the full GSP RPC stack trace leading up to it:
NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.
 _kgspRpcRecvPoll+0x716/0x13e0 [nvidia]
 _kgspRpcSendMessage+0xd3/0x190 [nvidia]
 _issueRpcAndWait+0xdd/0x920 [nvidia]
 rpcRmApiControl_GSP+0x76f/0x940 [nvidia]
 RmGssLegacyRpcCmd+0x1dd/0x3e0 [nvidia]
 _nv04ControlWithSecInfo+0x47/0xa0 [nvidia]
 RmIoctl+0x934/0xda0 [nvidia]
 nvidia_ioctl.isra.0+0x797/0xa70 [nvidia]
 nvidia_unlocked_ioctl+0x1d/0x30 [nvidia]
nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x0000ca7e:6:0:0x0000000f
NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (PF FLR)

So the hang is happening inside _kgspRpcRecvPoll — a userspace ioctl (RmIoctl → rpcRmApiControl_GSP) sends an RPC to the GSP and the wait for the reply (_issueRpcAndWait) never returns, which is what eventually gets reaped as Xid 79.

  • New detail: audio kept playing for a bit after the video output died this time (previous incidents I hadn’t checked for this specifically) — the video/modeset engine hung while the audio path stayed alive briefly, consistent with the failure being isolated to the display/GSP-RPC side rather than a total GPU-wide lockup. The log also shows the driver failing to cleanly tear down the DisplayPort audio stream as part of the failed recovery (Failed to disable DisplayPort audio stream-3).

Timing pattern across all 4 incidents — now looks very consistent

Incident Driver loaded Crash Time since boot
1 (Jul 23) ~11:11 ~11:11 (exact delta unknown, log rotated) early
2 (Jul 26) 12:00:59 12:02:25 ~1.5 min
3 (Jul 30) 22:58:43 23:07:38 ~9 min
4 (Jul 31) 10:59:07 11:19:12 ~20 min

In 4/4 occurrences, the crash has happened within the first ~20 minutes after boot, opening the browser + YouTube almost immediately after logging in. I have never had this happen after using the system for 30+ minutes or an hour. This looks less like a random YouTube-triggered fault and more like a race condition during the GPU/GSP’s early post-boot settling period — possibly related to power-state/ASPM negotiation, clock calibration, or the GSP firmware still completing initialization tasks, that a video-engine-heavy workload (browser + YouTube) can catch mid-transition.

Anecdotally (not GPU-related but possibly a symptom of the same “early boot is fragile” theme on this hardware): I also intermittently had no video output at all when powering on the PC before the monitor was powered on — resolved by powering the monitor on first. Not claiming these are the same bug, just noting the pattern of instability being concentrated right around boot/init.

Driver install history

Confirmed via rpm -q --last: akmod-nvidia-610.43.03-1.fc44.x86_64 was installed on 2026-07-15, i.e. 8 days before the first crash (Jul 23). So this isn’t a “crashed immediately after updating” situation — the driver had been running stably for over a week of normal use before the first Xid 79 showed up, which fits with the trigger being specific to a particular usage pattern (browser + YouTube right after boot) rather than a fresh-install regression.

Planned tests still pending

  • Haven’t yet been able to test “wait 20-30 min before opening YouTube” (Test A) or a second machine with an RTX 5060 as a control — will report back once I have.
  • Given the ~20 min-and-under pattern, I’m going to shift my Blender + YouTube-tutorial workflow to Windows for now (need YouTube open alongside Blender regularly, and can’t risk the crash mid-session), and keep the Linux side for non-YouTube work in the meantime.

Let me know if the stack trace above is useful for anyone with more visibility into the GSP RPC internals — happy to pull nvidia-bug-report.sh output if that would help further.

crash_log_31-07.txt (6.7 KB)

5

Check the factors mentioned below:

Not sure if you’ve checked any of them already: you posted a lot of AI-generated slop, so no human will bother to read carefully…

6

yes, 1. i dont speak english. 2. i dont know how to redact a good report. 3. i want a solution, i spend a lot of money for my gpu, this fails are not a joke for me. and 4. my three reports are little bit different. that’s the reason i post three reports writen by IA, if the logs are the same, i only upload one.

7

Have you tried replacing the PSU? Failures like this are usually caused by unstable or under-provisioned power output by the PSU during load transition. I personally had the same kind of crashes over and over, and most of the time during power transition / load spike. I swapped the GPU twice but still same issue. I did anything I could to workaround it but none of them helped. Finally I replaced the PSU with a more powerful one and has had no crash for two days. I know it is a short period of time but previously I had 15+ crashes a day.

8

+1 on this with a closely matching signature — same GPU chip (GB203), same Windows-clean asymmetry, and I’ve got fairly extensive logs if useful.

System:

  • GPU: RTX 5070 Ti (Gigabyte, 10de:2c05, vBIOS 98.03.58.00.DC)
  • Board: Gigabyte Z490 AORUS ULTRA, BIOS F24b (current)
  • CPU: i9-10900KF (no iGPU — no fallback display path)
  • OS: Zorin OS 18.1 (Ubuntu 24.04 base), kernel 7.0.0-31-generic
  • Display: 5120x1440 ultrawide over DP MST+DSC (Samsung Odyssey Neo G9-class panel)
  • Drivers tried: 580.173.02, 595.84-open, 610.57.04-open — all open kernel modules (required for this GPU). Crashes on all three; no version has fixed it.

Symptom: hard lock (“GPU has fallen off the bus,” kernel survives) during video calls in Brave (Google Meet / Teams). 11 Xid 79 events logged since Aug 20, all with the same GSP-RPC-timeout signature, at low power/low temp (40-60W, 40-55°C — not a thermal or power-delivery-under-load issue). AER counters stay at zero on every crash — no literal PCIe fault.

The one thing that’s held across every crash examined in detail: camera active via Brave (WebRTC) immediately before/during the crash. Never confirmed with the camera off. Refresh rate (240Hz vs. 120Hz) and driver version have both been ruled out as discriminators — crashes happen at both.

Never reproduces on a Windows dual-boot of the identical hardware, despite hours of gaming (heavier sustained load than any video call). That rules out a straightforward hardware/card/slot/cable explanation for me.

Mitigations tried, none effective:

  • Aux power cable reseat + full power drain — bought 11 clean days, then relapsed
  • Refresh rate capped to 120Hz — bought ~9 hours, then relapsed
  • NVreg_DynamicPowerManagement=0x00 — bought ~4 days (longest gap besides the cable reseat), then relapsed
  • --disable-video-capture-use-gpu-memory-buffer on Brave (avoiding GPU shared-texture upload for the local camera feed) — didn’t even last a day; a second crash followed 13 minutes after applying it

Most recent crash (Sep 21) added two new data points:

  • A kernel nvidia.ko WARNING: nvidia/nv.c:5346 at nvidia_dev_put+0xbf/0xd0 explicitly naming the browser process as the active context at the failure instant
  • A second crash 13 minutes later was preceded by NVRM: nvAssertFailedNoLog: Assertion failed: GPPut < WATCHDOG_GPFIFO_ENTRIES @ kernel_rc_watchdog.c:1551 — a GPU command-FIFO watchdog assertion, immediately before the Xid 79

Also relevant to a follow-up post in this thread (c.molinasalgado, Jul-Aug) reporting Xid 79 tied to browser/YouTube usage with a GSP RPC stack trace hung in _kgspRpcRecvPoll — that’s another browser-GPU-usage trigger on this exact GPU chip, independent of my own finding. And worth noting for anyone assuming this is Brave-specific: there’s a separate report of the identical trigger (Xid 79 during WebRTC webcam activation) on Firefox/KDE Wayland with an RTX 3090 — different browser engine entirely, so this looks like it’s in the driver/GSP layer that any GPU-accelerated WebRTC app touches, not something any one browser broke.

I’ve got full kernel logs, GPU telemetry CSVs at the moment of every crash, and I’m now running nvidia-bug-report.sh --safe-mode automatically on every occurrence (via a small watcher script) — happy to attach whichever of these would be most useful if anyone’s actively looking at this.

9

Just an update to my post, my PSU is probably 3 or 4 months old and is a 1,000 watt PSU.