Bug Report: GPU Reset / "Illegal opcode in command stream" crash in V Rising (Linux, RADV/RDNA3)

Evidence collected

Incident 1 — RADV-side rejection (no full GPU reset)

radv/amdgpu: The CS has been rejected, see dmesg for more information (-2).

Game process terminated shortly after; no further kernel detail was captured for this specific incident (persistent journal logging was not yet enabled at the time).

Incident 2 — glibc heap corruption during shutdown

steam: Trying to close low level socket support, but we still have sockets open!
steam: malloc(): unaligned tcache chunk detected

Occurred during game process teardown; distinct from the GPU reset events but suspected to be a downstream symptom of the same underlying instability.

Incident 3 — Full kernel GPU reset with cascading crash (most detailed capture)

kernel: amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=2197973, emitted seq=2197975
kernel: amdgpu 0000:03:00.0: Process VRising.exe pid 11725 thread dxvk-submit pid 11801
kernel: [drm:gfx_v11_0_bad_op_irq [amdgpu]] *ERROR* Illegal opcode in command stream
kernel: amdgpu 0000:03:00.0: Starting gfx_0.0.0 ring reset
kernel: amdgpu 0000:03:00.0: MES failed to respond to msg=RESET
kernel: amdgpu 0000:03:00.0: failed to reset legacy queue
kernel: amdgpu 0000:03:00.0: reset via MES failed and try pipe reset -110
kernel: amdgpu 0000:03:00.0: The CPFW hasn't support pipe reset yet.
kernel: amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset failed
kernel: amdgpu 0000:03:00.0: GPU reset begin!. Source: 1
kernel: amdgpu 0000:03:00.0: MES failed to respond to msg=REMOVE_QUEUE
kernel: amdgpu 0000:03:00.0: failed to unmap legacy queue
kernel: [drm:gfx_v11_0_hw_fini] *ERROR* failed to halt cp gfx
kernel: amdgpu 0000:03:00.0: MODE1 reset
kernel: amdgpu 0000:03:00.0: GPU mode1 reset
kernel: amdgpu 0000:03:00.0: GPU smu mode1 reset
kernel: amdgpu 0000:03:00.0: GPU reset succeeded, trying to resume
kernel: amdgpu 0000:03:00.0: VRAM is lost due to GPU reset!
kernel: amdgpu 0000:03:00.0: GPU reset(1) succeeded!
kernel: amdgpu 0000:03:00.0: [drm] device wedged, but no recovery needed
kernel: amdgpu 0000:03:00.0: [drm] *ERROR* Failed to initialize parser -125!
kernel: QSGRenderThread[2420]: segfault at 10 ip 00007f4999ebb0d7 sp 00007f492610c9b0 error 4 in libc.so.6

Immediately following this reset, the following unrelated processes also crashed as a direct result of the lost GPU context:

kwin_wayland_wrapper: amdgpu: The CS has cancelled because the context is lost. This context is innocent.
Xwayland (pid 2090): terminated abnormally with signal 6/ABRT
plasmashell: Main process exited, code=dumped, status=11/SEGV
Discord (both running instances): terminated abnormally with signal 11/SEGV
steam: src/common/pipes.cpp (900): fatal stalled cross-thread pipe (pipe is disconnected)
firefox: [GFX1-]: Detect DeviceReset DeviceResetReason::DRIVER_ERROR

Incident 4 — Second GPU reset, game freeze instead of crash

Occurred in a later session after adding DXVK_ASYNC=0 and switching to Proton Experimental:

kernel: amdgpu 0000:03:00.0: GPU smu mode1 reset
kernel: amdgpu 0000:03:00.0: GPU reset succeeded, trying to resume
kernel: amdgpu 0000:03:00.0: VRAM is lost due to GPU reset!
kernel: amdgpu 0000:03:00.0: GPU reset(2) succeeded!
kernel: amdgpu 0000:03:00.0: [drm] device wedged, but no recovery needed
kernel: QSGRenderThread[12270]: segfault at 10 ip 00007f7057abb0d7 sp 00007f6fcafc9530 error 4 in libc.so.6

Following this, VRising.exe did not crash but instead became unresponsive while consuming ~239% CPU (busy loop, GPU itself idle at 39W/327W cap afterward — consistent with the render thread stuck retrying against a lost GPU context). Steam also crashed shortly after via the same X11 connection-loss cascade:

steam: radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent.
steam: XIO: fatal IO error 110 (Connection timed out) on X server ":0"

What was tried

The following launch options / configuration changes were tested and did not prevent the underlying illegal-opcode trigger (though they changed how the aftermath manifested):

• DXVK_ASYNC=0 (forces synchronous shader compilation)
• RADV_DEBUG=nohang
• Proton Experimental (in place of a CachyOS-provided Proton build)
• PROTON_ENABLE_WAYLAND=1

GPU was confirmed to be running at stock clocks/voltages throughout (no overclock/undervolt software installed — no LACT, no CoreCtrl). Temperatures and power draw were normal/idle both before and after incidents; this does not appear to be thermal or power-delivery related.

Related upstream reports

A similar "Illegal opcode in command stream" GPU-hang pattern on the same GPU generation (RX 7900 XTX / RDNA3) has been reported for other games under DX12/VKD3D-Proton (tracked upstream at HansKristian-Work/vkd3d-proton#3004), where extensive testing across multiple Proton versions and kernel parameters did not resolve it. A separate report on an older AMD GPU (RX 5700) showed the same gfx_0.0.0 ring / dxvk-submit thread signature in a different game (Deadlock), suggesting this may be a broader RADV/DXVK command-stream validation gap rather than something specific to V Rising alone.

Suggested next steps for maintainers

• Since the illegal opcode originates from V Rising's DXVK command submission (DX11 via DXVK, not DX12/VKD3D), this may point to a specific D3D11 call pattern in V Rising that DXVK translates into an invalid GFX11 command on RDNA3.
• A /sys/class/drm/card1/device/devcoredump/data GPU coredump was noted as available immediately after Incident 3 in the kernel log (AMDGPU device coredump file has been created) but was not captured before rotation — capturing this on a future occurrence would give Mesa/RADV maintainers much more actionable detail.