NVIDIA Xid 109 CTX SWITCH TIMEOUT: Fix Linux Game Crashes

on

Frozen first-person game scene with terminal-style kernel log showing NVRM Xid 109 CTX SWITCH TIMEOUT — fix NVIDIA Linux game crashes

 

In this guide:

You are mid-match, mid-boss-fight, mid-save — and the game just stops. The picture freezes. The audio keeps playing for a second or two, then loops. Your desktop is fine. Alt-Tab still works. The game window is a tombstone.

You dig through the logs, and there it is, one cryptic line:

NVRM: Xid (PCI:0000:01:00.0): 109, pid=20891, name=game-proc, CTX SWITCH TIMEOUT

This is NVIDIA's Xid 109 error, and if you are running the 615 driver branch on Linux in October 2026, you are very likely not alone. NVIDIA has filed four internal bugs against this crash in a five-day span, the DXVK maintainers merged a fix that "seems to resolve" the hangs, and the community has isolated exactly which Vulkan extension is doing it. Here is the full decoder — what the error means, how to confirm it is really Xid 109, and every workaround worth trying, ranked by how confident we can be in each one.

Update: October 28, 2026. No newer 615-branch driver has appeared in NVIDIA's driver listing since 615.78.08. The 615.71.09 highlights list one Xid 109 fix, an error when loading PRAGMATA on Wayland, and there is still no driver fix for the context-switch-timeout freeze described in this post. The DXVK change that addresses the Deadlock hang, pull request 5958, was merged into DXVK's master branch on October 10, 2026, but it has not appeared in a released DXVK version, so it is still not in a stable Proton release. The workarounds in this post are unchanged.

What Xid 109 "CTX SWITCH TIMEOUT" actually means

NVIDIA's Xid messages are the driver's way of reporting general GPU errors — they usually mean the driver misprogrammed the hardware or issued corrupted commands, and NVIDIA documents them as debugging tools rather than user-facing errors. Think of each Xid code as the kernel's crash dump for one bad moment.

Code 109 is named CTX SWITCH TIMEOUT. A "context switch" here has nothing to do with CPU process switching — it is the GPU moving from one rendering context (your game) to another (the desktop compositor, a background app). The GPU has a watchdog on that handoff: if the channel does not complete its context switch in time, the driver tears the channel down. That teardown is the freeze. Your desktop survives because it lives on a different GPU channel; the game channel is dead.

Three things this error does not mean:

  • It is not proof your GPU is dying. Xid 109 is about a missed deadline on one channel, not broken silicon. If the crash only appeared after a driver update, that alone points at software.
  • It is not a temperature problem by itself. Overheating can cause Xid codes, but the current wave hits users with normal thermals — the signature is the driver version, not the sensors.
  • It is not a Proton bug. Proton and DXVK merely feed the driver the workloads that trip it. The timeout is reported by NVRM, NVIDIA's own kernel module.

How to confirm it is really Xid 109 (2 minutes)

Before changing anything, confirm the error in your kernel log. You want the exact code 109 — similar crashes (Xid 8, Xid 13, Xid 31) have different causes and different fixes.

Step 1. After a crash, open a terminal and search the kernel ring buffer:

sudo dmesg | grep -i "NVRM: Xid"

Step 2. Or search the persistent journal for the current boot (works even if you already rebooted once):

journalctl -k -b | grep -i "NVRM: Xid"

Step 3. You are looking for a line exactly like this:

NVRM: Xid (PCI:0000:01:00.0): 109, pid=20891, name=game-proc, CTX SWITCH TIMEOUT

The name= field tells you which process was on the dead channel — on Proton games it is usually the game's process or wine64-preloader. The companion symptoms that confirm the diagnosis: the image froze while the desktop stayed alive, audio played on briefly (that's the audio thread on a different path), and DXVK or vkd3d-proton reported VK_ERROR_DEVICE_LOST in the game's log before it died.

If your log shows Xid 8 instead, you are looking at the RTX 5090 GSP firmware heartbeat failure documented in the open kernel modules tracker — a different beast, covered near the end of this post. If it shows Xid 13 or Xid 31, those are graphics engine exceptions with their own causes.

One note before you go further: this guide is Linux-specific. If your game crashes are happening on Windows after an update, the cause is almost certainly different — see our guide to game crashes caused by a Windows update instead. And if your game launches fine on Windows but refuses to go online at all, Modern Warfare 4's TPM 2.0 and Secure Boot requirement may be the blocker — enable both in BIOS before the DMZ early access period. And if you are new to reading kernel logs to find the culprit, the technique is the same one we used to track down the midnight dasd bug on macOS.

Why Xid 109 is spiking in October 2026

This is not a random regression — it is a dated, documented wave with a paper trail:

  • Driver 615.78.08 shipped on October 7, 2026 with six release-note items — and nothing for Xid 109. Reporters confirmed the crash persists on the new build the same day it launched.
  • NVIDIA filed four internal bugs in five days: 6756147 and 6869685 (October 4), 6878084 (October 6), and 6899071 (October 8). For two of them NVIDIA confirmed an internal reproduction — the company can reproduce the crash on its own rigs.
  • The isolated repro: NVIDIA's open kernel modules issue #1409 documents a Deadlock Xid 109 reproducible on demand on an RTX 2070 with driver 615.71.09, isolated to the VK_NV_raw_access_chains Vulkan extension. Toggle that extension off and the hang disappears.
  • The DXVK response: on October 10, DXVK maintainer Philip Rebohle merged PR 5958 ("Merge overlapping buffer loads"), which he says "seems to resolve some hangs with NV_raw_access_chains" — with the caveat that it is D3D11-only and needs testing. As of this writing it is not in any stable Proton build.
  • The pattern: users report no Xid 109 on the 595.99.02 production driver or the 580/590 lines — the crashes arrived with the 610/615 branch. This is a regression, not hardware decay.

Fix 1: Disable NV_raw_access_chains in DXVK (strongest community evidence)

This is the one workaround isolated to a root cause rather than a guess. In the #1409 repro, the reporter found the Xid 109 hang disappears when the raw-access-chains extension is disabled.

Step 1. In Steam, open your game's Properties → General → Launch Options, or set the environment variable in your launcher (Lutris, Heroic):

dxvk.enableNvRawAccessChains=False %command%

Step 2. Launch the game and play through the scenario that used to freeze it — the crash in the reporter's case was reproducible on demand, so you should know within one session whether it worked.

This is a D3D11-path fix. It will not help D3D12 games running through vkd3d-proton — those need Fix 3 below.

Fix 2: Update DXVK past PR 5958 (for D3D11 games)

PR 5958's merge is the closest thing to an official fix on the horizon. Once Proton ships a DXVK build that includes it, updating your Proton version becomes the first thing to try. Check your distro's or GE-Proton's release notes for a DXVK version newer than the October 10 merge before pinning old drivers. Until then, Fix 1 is the practical substitute.

Fix 3: VKD3D_CONFIG=descriptor_heap (D3D12 path-tracing crashes)

An October 8 reporter found that path-tracing save-load crashes eased with the vkd3d descriptor-heap configuration:

VKD3D_CONFIG=descriptor_heap %command%

Confidence level: low to moderate — this is one reporter's observation, not a confirmed fix. It costs nothing to try, and it is reversible by removing the variable.

Fix 4: Pin the driver to 595.99.02 (the regression dodge)

If the workarounds above do not cover your game, the community's most-reported escape is leaving the 610/615 branch entirely. Multiple users report no Xid 109 on driver 595.99.02 (the current production branch) or the 580/590 lines.

How you do this depends on your distro — Ubuntu users can pick the driver in "Additional Drivers" or pin the package version, Arch/CachyOS users can downgrade via the package cache. The trade-off: you lose the 615 branch's newest game profiles and fixes (including the Last of Us Part II corruption fix in 615.78.08). Treat this as a temporary bunker, not a permanent home — revisit once NVIDIA's bug numbers close.

Fix 5: NVIDIA power-management module parameters

A community guide tested on an RTX 3060 reports that enabling NVIDIA's runtime power management calms the crashes. Add these to your modprobe configuration (e.g. /etc/modprobe.d/nvidia-power.conf):

options nvidia NVreg_DynamicPowerManagement=2
options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia-drm modeset=1

Then rebuild your initramfs and reboot. Confidence level: moderate — widely shared, but it addresses power-state transitions, which is a plausible-but-unproven mechanism for the timeout. If your crashes happen during scene loads or resolution changes (GPU clock transitions), this one is worth trying before the driver downgrade.

Fix 6: Check whether you are on the open or proprietary kernel module

On RTX 5090-class cards, a separate root-cause analysis found the real failure was a GSP firmware heartbeat timeout — the firmware died, and Xid 109 was just the downstream symptom. Raising the context-switch timeout had no effect there, because the switching was never the problem.

If you are on the open kernel modules, try the proprietary ones (or vice versa) to see which side of the GSP firmware path your crash follows. This is a diagnostic step more than a fix — but knowing which module set crashes tells you whether you are waiting on a firmware fix or a driver fix.

What not to waste time on

  • Raising RmEngineContextSwitchTimeoutUs. It did nothing in the GSP-heartbeat case and it does not address a watchdog that fires because the channel is already dead.
  • Reinstalling the game. The corruption is in the driver-GPU channel, not the game files.
  • Buying a new GPU. The regression arrived with a driver branch and NVIDIA is reproducing it internally. This is software.

When to file a report with NVIDIA

If none of the fixes above help, make your report the one that gets fixed: NVIDIA's own feedback topic for the 615 driver has 220 replies and four bug numbers, and the company is actively reproducing. Run nvidia-bug-report.sh as root right after a crash (it captures the Xid lines and your driver state), and attach it to your post with your exact driver version, game, Proton/DXVK version, and GPU model. The reports that led to the four October bug filings all had one thing in common: exact version numbers and reproducible steps.

FAQ

What does NVIDIA Xid 109 mean?

Xid 109, "CTX SWITCH TIMEOUT", means a GPU channel failed to complete a context switch before the driver's watchdog timer fired, so the driver tore the channel down. In practice on Linux gaming setups in October 2026, it freezes the game while the desktop stays alive, usually on NVIDIA driver branch 610/615 through Proton, DXVK, or vkd3d-proton.

Does Xid 109 mean my GPU is dying?

Almost certainly not. Xid 109 is a missed deadline on one GPU channel, not broken silicon. The current wave is a driver-branch regression: users report no crashes on driver 595.99.02 or the 580/590 lines, and NVIDIA is reproducing the crash internally, which points at software, not hardware.

Does driver 615.78.08 fix Xid 109?

No. NVIDIA released 615.78.08 on October 7, 2026 with six release-note items and none addressed Xid 109 — reporters confirmed the crash persists on the new build the same day. NVIDIA has filed four internal bug numbers (6756147, 6869685, 6878084, 6899071) but has not shipped a fix yet.

What is the difference between Xid 109 and Xid 8?

Xid 109 is a context-switch timeout that kills one GPU channel — the game freezes but the system lives. Xid 8 is a GPU channel exception with broader causes, and on RTX 5090 cards in 2026 it has been tied to a GSP firmware heartbeat failure, where the firmware dies and Xid 109 appears only as a downstream symptom. They share a log line but have different root causes and different fixes.

How do I report Xid 109 to NVIDIA?

Run sudo nvidia-bug-report.sh as root right after a crash, then post to NVIDIA's Linux driver feedback topic with the report attached, plus your exact driver version, game, Proton or DXVK version, and GPU model. Include the full Xid 109 line from journalctl -k -b | grep -i "NVRM: Xid" so your crash can be matched to the four bug numbers NVIDIA already filed in October 2026.


About the author

Bilal runs The Glitch Fixer and The Homelab Fixer, publishing hands-on guides that solve app, game, and AI errors step-by-step, plus NAS, Docker, and self-hosting fixes.