RTX 5050 Laptop GPU (GB107 Blackwell, 10de:2d98): Xid 109 CTX SWITCH TIMEOUT / GPU TDR on compute shader dispatch in gaming workload

[EMalpha01]

NVIDIA Open GPU Kernel Modules Version

595.71.05

Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.

• I confirm that this does not happen with the proprietary driver package.

Operating System and Version

Linux Mint 22.3

Kernel Release

Linux Alienware-Aurora 6.17.0-1025-oem #25-Ubuntu SMP PREEMPT_DYNAMIC Fri May 29 12:11:29 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.

• I am running on a stable kernel release.

Hardware: GPU

GPU 0: NVIDIA GeForce RTX 5050 Laptop GPU (UUID: GPU-1d050d72-2f3b-992a-f0a5-2ebf3f3916f1)

Describe the bug

The GPU crashes with TDR (Timeout Detection and Recovery) within minutes of gameplay in Warhammer 40,000: Space Marine 2 running via Steam/Proton on Linux. The GPU hangs on compute shader dispatches, producing Xid 109 CTX SWITCH TIMEOUT at the kernel level (with default NVreg_DynamicPowerManagement) and VK_ERROR_DEVICE_LOST at the Vulkan API level regardless of NVreg settings.

The crash is fully reproducible and occurs across both DX12 (VKD3D-Proton) and DX11 (DXVK) rendering paths, ruling out the translation layer as the cause. All user-side mitigation attempts have been exhausted.

Related to issue #962 (same Xid 109 CTX SWITCH TIMEOUT on RTX 5080 Blackwell while gaming, confirmed driver regression from 570.x). This report adds a second Blackwell GPU (RTX 5050, GB107) and a second game title affected.

To Reproduce

• Install Warhammer 40,000: Space Marine 2 via Steam
• Set Steam Play compatibility to Proton Experimental
• Set the following Steam launch options: PROTON_LOG=1 VKD3D_CONFIG=no_upload_hvv SDL_VIDEODRIVER=x11 %command%
• Launch the game and allow it to load fully into the battle barge hub scene (hub_battle_barge)
• The GPU stops responding to compute shader dispatches within minutes. The game engine detects TDR internally and terminates with a crash dump.
• With default NVreg_DynamicPowerManagement, the kernel simultaneously logs Xid 109 CTX SWITCH TIMEOUT.

Bug Incidence

Once

nvidia-bug-report.log.gz

Always — 100% reproducible within minutes of launching

nvidia-bug-report.log.gz

the game. sometimes I make it through to the battle barge, sometimes before.

More Info

System

• Machine: Alienware Aurora 16 (AC16250)
• CPU: Intel Core i7-240H
• RAM: 15.7GB
• GPU: NVIDIA GeForce RTX 5050 Laptop GPU (Blackwell GB107, PCI ID: 10de:2d98)

Proprietary driver checkbox is unchecked — reason
Testing with the proprietary driver is not possible on this hardware. The kernel rejects it with:
NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:2d98) installed in this system requires use of the NVIDIA open kernel modules.

Kernel-level evidence (with default NVreg_DynamicPowerManagement)
NVRM: Xid (PCI:0000:01:00): 109, pid=17365, name=Warhammer 40000, channel 0x00000011, errorString CTX SWITCH TIMEOUT, Info 0x16c012

Also observed in DX11/DXVK mode:
NVRM: Xid (PCI:0000:01:00): 109, pid=17513, name=Warhammer 40000, channel 0x00000013, errorString CTX SWITCH TIMEOUT, Info 0x5c016

With NVreg_DynamicPowerManagement=0x02 and =0x00, Xid 109 is suppressed at the kernel level. The game engine's internal TDR detection confirms the GPU hang still occurs regardless.

Game engine crash data (extracted from crash_data.zip, Saber Interactive crash reporter)

Crash 1 — DX12, default NVreg:
message: GPU crash: reason: TDR, marker: PURGE_GPU_PARTICLES_EMISSION_BEGIN
active scene: title_scene
GPU graphics queue: BOP=PURGE_GPU_PARTICLES_EMISSION_BEGIN, TOP=PURGE_GPU_PARTICLES_EMISSION_END (never completed)
kernel_session_id: 663e9796-622a-81f1-bf1f-000d3a4b5396

Crashes 2 and 3 — DX12, NVreg_DynamicPowerManagement=0x02 and =0x00:
message: GPU crash: reason: TDR, marker: COMPUTE_INST_INDEX_BEGIN
active scene: hub_battle_barge
GPU graphics queue: BOP=COMPUTE_INST_INDEX_BEGIN, TOP=COMPUTE_INST_INDEX_BEGIN (accepted, never completed)
GPU async compute queue: stalled at DECALS_TILE_MASK_END
kernel_session_ids: 8237ad73-629c-81f1-bda1-00224885ea7d, 9af510d2-62a0-81f1-b0cd-00224883b165

Vulkan API evidence (Proton log, PROTON_LOG=1)
err:winevulkan:signaller_worker wait timed out with non-empty poll list.
err:vkd3d-proton:d3d12_command_queue_execute: Failed to submit queue(s), vr -4.
warn:vkd3d-proton:d3d12_device_mark_as_removed: Device is lost (reason 0x887a0005, "VK_ERROR_DEVICE_LOST").

The winevulkan signaller_worker times out on GPU semaphore completion before the queue submission failure, indicating the GPU stops responding prior to the fatal submit.

Mitigation attempts — all failed

• Driver 580-open → 595-open: No effect
• Proton versions GE-Proton 10.34, Proton Experimental, Proton-hotfix, Proton 11: No effect
• DX11 via DXVK (PROTON_USE_D3D11=1): Xid 109 on different channel (0x00000013), same TDR failure
• VKD3D_CONFIG=no_upload_hvv: Confirmed applied by log, no effect
• VKD3D_CONFIG=no_upload_hvv,force_host_cached + VKD3D_FEATURE_LEVEL=12_1: No effect
• NVreg_DynamicPowerManagement=0x02: Suppresses Xid 109 kernel log, TDR persists
• NVreg_DynamicPowerManagement=0x00: TDR persists

The crash reproduces in both DX12 and DX11 paths, confirming the fault is below the translation layer and resides in the driver or GSP firmware.

Relation to issue #962
Issue #962 reports identical Xid 109 CTX SWITCH TIMEOUT on RTX 5080 (Blackwell GB103) while gaming. That reporter confirmed the issue does not occur with driver 570.153.02, establishing it as a regression introduced in 580+. The RTX 5050 requires 580+ for hardware support, making the 570 rollback unavailable on this system. This report demonstrates the regression affects at least two distinct Blackwell GPU models (GB103 and GB107) across multiple game titles.

[Rohithmatham12]

I took a quick look at the open-module side of this after comparing this report with #962. One useful signal is that the observed behavior matches the split between error reporting and the underlying hang:

• the Xid text is delivered through the GSP-RM error-log path and then logged by the kernel module;
• changing NVreg_DynamicPowerManagement appears to affect whether Xid 109 is surfaced in the kernel log, but not whether the GPU stops making progress, because the game still reports TDR / VK_ERROR_DEVICE_LOST;
• reproducing in both DX12/VKD3D-Proton and DX11/DXVK makes this look below the translation layer, likely in the Blackwell GSP/RM scheduling or context-switch path rather than a game-specific API frontend issue.

That makes this a strong companion to #962: #962 gives a GB103/RTX 5080 case with a reported 570.x -> 580+ regression window, while this issue gives a GB107/RTX 5050 Laptop case where 570.x rollback is unavailable because the GPU requires open modules. The most useful maintainer-side comparison seems to be whether both reports share the same GSP/RM context-switch timeout path despite different games and channels (0x11, 0x13, 0x18) and slightly different Xid info values.