Last post ended with a clock lock applied and a promise: whether it held, or whether Xid 79 found a way through it too. It’s been six days. Here’s the answer.

The number that matters

$ uptime -s
2026-08-21 04:19:04

No reboot since. The clock lock (nvidia-smi -lgc 180,2400) went in at 14:28:36 that same day, so this window covers roughly ten hours of the old, unlocked behavior first, then everything after — and the kernel log doesn’t care which half you look at:

$ sudo journalctl -k --since "2026-08-21 04:19:00" | grep -ic "NVRM: Xid"
0

Zero. Across 6 days, 17 hours of real uptime, under the same vllm-coder.service workload that produced five Xid 79s in the four days before the lock went in — the last of which took only 22 minutes to reproduce with every other mitigation active. The previous best clean window, logged in the last post as “significant,” was 14 hours. This is that number times ten, and counting.

I pulled the SM clock telemetry directly from Prometheus rather than trust the uptime figure on its own — same discipline as every other checkpoint in this investigation, because “looks fine” and “is fine” have diverged on this box before:

$ curl -sG localhost:9090/api/v1/query \
  --data-urlencode 'query=max_over_time(nvidia_smi_clocks_current_sm_clock_hz{job="gpu"}[150h])'
→ 2392000000  (2392 MHz)

$ curl -sG localhost:9090/api/v1/query \
  --data-urlencode 'query=count_over_time((nvidia_smi_clocks_current_sm_clock_hz{job="gpu"} > 2400000000)[150h:15s])'
→ (empty result — zero samples)

36,000 samples at 15-second resolution over 150 hours, peak clock 2392 MHz, not one sample above the 2400 MHz cap. The lock hasn’t slipped once.

What this means for the RMA

I’m formally withdrawing the RMA request. The motherboard I had on order — the one the first post in this series treated as the likely fix, and the one later posts downgraded to “diagnostic step, not expected resolution” as the community evidence piled up against a board-level cause — never got installed. I cancelled the order once the clock lock had cleared the bar I’d set for it: outlasting every previous mitigation combination by an order of magnitude, under real traffic, independently verified rather than taken on trust. It never shipped back for a refund because it never left the box it arrived in.

Worth being precise about what actually got resolved here, because it isn’t “the hardware was fine all along.” Everything in the RMA report still stands: five identical Xid 79/154 faults, every driver-level and BIOS-level mitigation tried and individually verified in effect, a clean 4-hour max-load burn test that turned out to be structurally incapable of testing the actual trigger condition, and two independent public reports of the same signature on the same GPU family pointing at a GSP-firmware/power-state-transition interaction below the driver boundary. None of that got un-found. What changed is that a fix for exactly that failure mode — capping the boost clock so it can’t spike toward its rated ceiling during the idle-to-burst and micro-idle-gap transitions where all five crashes happened — has now run six times longer than the investigation needed to convince itself the hardware was broken. At some point “still holding” stops being a data point and starts being the answer.

What I still don’t know, on purpose stated plainly

This series has a running theme of mitigations that looked confirmed and weren’t — an empty override file, a persistence-mode flag silently reverted by a daemon’s own default flag, a kernel parameter that did nothing at the hardware level. In that spirit, here’s what this result doesn’t prove:

  • Reboot-persistence of the clock lock is still untested in practice. The systemd unit (nvidia-clock-lock.service) is enabled and systemctl is-enabled reports it correctly wired to reapply on boot, but the box hasn’t rebooted since before the lock was even applied — so “wired correctly” and “actually reapplies after a real reboot” remain two different claims, and only the first one is checked. Next reboot, whenever that happens, I’ll verify it directly rather than assume.
  • I don’t fully know why this works, only that it does. The theory — a transient boost-clock excursion during a load-state transition, exceeding what the GSP firmware or silicon can handle cleanly — comes from a Reddit comment about an unrelated card and my own reading of the burn-test telemetry gap. It’s a mechanism that fits every fact on file, not a confirmed root cause.
  • vllm-coder.service is still Restart=on-failure, not Restart=always, and there’s still no external alerting on it going down. Three of the five outages in this saga went unnoticed for hours because nothing paged anyone. The clock lock fixes the crash; it doesn’t fix the blast radius if something else takes the service down. Still on the list.

Closing out

Total cost of this investigation: a lot of journalctl, one BIOS trip, a returned motherboard order, and about ten days between the first Xid 79 and a clean week. Total cost of the fix that actually held: one command and a systemd unit to make it stick.

If you’re chasing an Xid 79 on Blackwell-class silicon and you’ve already ruled out thermal, ECC, RAM, and PCIe signal integrity — check what your boost clock is doing on the transitions your stress test doesn’t reproduce, not just under sustained load. That gap is where mine was hiding the whole time.