A fix for the Xid 109 hang in Deadlock landed in DXVK, not in Nvidia's driver
A fix for the freeze that Linux players have been logging as an Nvidia Xid 109 has landed in DXVK, the translation layer Proton uses to run Direct3D games on Vulkan. Pull request 5958, "Merge overlapping buffer loads", was opened on October 8 and merged into DXVK's master branch at 11:39:55 UTC on October 10, read at 21:46 UTC the same day.
The reproduction picks a hero, enters Deadlock's testing range and casts two abilities, on the game's default DirectX 11 renderer. Image: Valve
The claim attached to it is hedged by the person who wrote it, DXVK maintainer Philip Rebohle. The change adds a pass that resolves overlapping buffer loads, and then the description says: "For some reason this seems to resolve some hangs with NV_raw_access_chains, but this might be a good idea in general." It also asks for "a bunch of testing (D3D11 only)".
One Vulkan extension, isolated by repetition
The report it points at is issue 1409 on Nvidia's open kernel module tracker, opened on September 30 and still open. It describes Deadlock, Valve's unreleased hero shooter, freezing permanently on an RTX 2070 running the 615.71.09 open driver, with the audio carrying on after the picture stops and the rest of the desktop unaffected.
What lifts it above the usual crash report is that the person who filed it isolated the trigger before filing, and published the table showing it. Same driver, same kernel, same Proton build, same four steps in the game's testing range, three times over: with VK_NV_raw_access_chains in use, Xid 109 every time; with dxvk.enableNvRawAccessChains=False, "No hang, no Xid, no DEVICE_LOST"; with DXVK's descriptor heap switched off but the extension left on, Xid 109 again. The fault tracks the extension and ignores the binding model.
Two more machines sit underneath, both on the same 615.71.09 open kernel module. One reports the identical hang and the identical workaround on an RTX 5070, a Blackwell GB205 part rather than the original Turing card. Another runs an RTX 3050 Laptop GPU, where the Xid arrived in Genshin Impact 7.1.0 after about an hour and a half rather than on demand. These are reports from users, not Nvidia's account of a defect.
Nvidia has not posted in that thread
The error string belongs to Nvidia's kernel module and the fix does not, so the wording needs care. Every comment on issue 1409 carries an author association of NONE, so nobody speaking for Nvidia has written in it at all. Xid 109 with the string CTX SWITCH TIMEOUT is what the kernel module prints when a context switch runs out of time, which is a symptom rather than a diagnosis.
The only suggestion that the freeze is dealt with comes from a DXVK contributor, who posted on the issue at 15:28 UTC on October 10: "The deadlock hang should be gone on dxvk master."
Merged to master is not the same as shipped
Master is where DXVK development happens, and Proton ships its own bundled build rather than tracking that branch, so no released Proton carries this yet. The author's own scope, D3D11 only, also leaves out the vkd3d-proton side where similar reports have been filed, and his request for testing is not a closing statement.
The shape of it is still unusual. A hang that reads in the kernel log as a graphics driver timing out turns out to follow one Nvidia Vulkan extension, and the change that appears to settle it is one commit touching two files in a community project, written by somebody whose own account of why it works begins "For some reason". Linux gaming often runs on that kind of repair, from Proton Experimental picking up early 32-bit OpenXR support to Valve's Proton maintainer turning down a crash fix over where the code came from. Whether it clears the Xid for the people who filed the reports is now a question for them.
