Re: RX 7900 XTX (GFX11/Navi31): "Illegal opcode in command stream" gfx ring timeout, worked around by amdgpu.user_queue=0

On 2026. június 14., vasárnap 16:11:11 közép-európai nyári idő Miles Margetts 
wrote:
> Hello,
> 
> I'd like to report a reproducible GFX11 GPU hang on an RX 7900 XTX,
> along with a workaround that seems to point at the user-mode queue path.
> I'm not submitting a patch, just flagging it in case it's useful and
> asking whether a devcoredump would help narrow it down.
> 
> System:
> - GPU: AMD Radeon RX 7900 XTX, Sapphire NITRO+ (board 11322-01-40G),
> Navi 31 / GFX11 (PCI 1002:744c)
> - Secondary: Raphael iGPU (1002:164e), not used for display
> - CPU: AMD Ryzen 7 7800X3D
> - Kernel: 7.0.11 (CachyOS, Arch-based)
> - Mesa / RADV: 26.1.2 (vulkan-radeon)
> - Session: KDE Plasma 6 on Wayland. The failing client is Xwayland: the
> affected app is the native Linux build of Baldur's Gate 3, which runs as
> an X11 client under Xwayland.
> - GPU tuning via LACT: Overdrive enabled, core clock capped at 2600 MHz,
> voltage offset -20mV, framerate capped at 71. NOTE: these were unchanged
> across both the crashing and non-crashing states, so they are not the
> variable (details below).
> 
> Symptom:
> Intermittent full GPU hang during gameplay. The gfx ring times out
> immediately after an "Illegal opcode in command stream", the ring and
> MES resets fail, and a MODE1 reset recovers the GPU but loses VRAM and
> wedges the display, requiring a reboot. Representative dmesg:
> 
> amdgpu 0000:03:00.0: [drm] AMDGPU device coredump file has been created
> amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=38937911,
> emitted seq=38937913
> amdgpu 0000:03:00.0: Process Xwayland pid 1063 thread Xwayland:cs0 pid 1071
> amdgpu 0000:03:00.0: Starting gfx_0.0.0 ring reset
> [drm:gfx_v11_0_bad_op_irq [amdgpu]] *ERROR* Illegal opcode in command stream
> amdgpu 0000:03:00.0: MES failed to respond to msg=RESET
> amdgpu 0000:03:00.0: failed to reset legacy queue
> amdgpu 0000:03:00.0: reset via MES failed and try pipe reset -110
> amdgpu 0000:03:00.0: The CPFW hasn't support pipe reset yet.
> amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset failed
> amdgpu 0000:03:00.0: GPU reset begin!. Source: 1
> amdgpu 0000:03:00.0: MODE1 reset
> amdgpu 0000:03:00.0: GPU reset succeeded, trying to resume
> amdgpu 0000:03:00.0: VRAM is lost due to GPU reset!
> amdgpu 0000:03:00.0: GPU reset(1) succeeded!
> amdgpu 0000:03:00.0: [drm] device wedged, but recovered through reset
> 
> Reproduction:
> - Occurs only in Baldur's Gate 3 (native Linux build) when playing
> multiplayer as the CLIENT.

Can you please write how to reproduce this?

> - Stable in single-player and as the multiplayer HOST, with identical
> settings in the same session.
> - Onset varies from a few minutes to longer stretches of client play.
> 
> Things tried:
> - RADV_DEBUG=nongg: no effect, so it does not appear to be NGG-related.

You cannot disable NGG on the 7900 XTX because it only has the NGG pipeline 
and no longer has the legacy geometry pipeline. So RADV_DEBUG=nongg doesn't do 
anything on this GPU.

> - The undervolt/clock settings are not the trigger: the system is stable
> as host and in single-player with the exact same tuning, and -20mV is a
> mild offset.

Overclock / undervolt related instability is usually non-deterministic, so I 
would feel more confident in this finding if you could reproduce it with 
overdrive disable and putting the GPU in "profile_standard" mode.

> Workaround that appears to resolve it:
> - Booting with amdgpu.user_queue=0 (disabling GFX11 user-mode queues).
> Since applying it, client sessions that previously hard-froze have been
> stable.

RADV does not support user queues yet, so this is not doing anything for the 
game. Are you running anything else on your system that may be using user 
queues?

> 
> This seems to point at the GFX11 user-queue path (queue evict/restore /
> MES queue handling) rather than RADV shader codegen, but I have not
> root-caused why the malformed packet is emitted.

As far as I know the "Illegal opcode in command stream" refers to packets in 
the command stream and not shader instructions. So this doesn't have anything 
to do with shader code gen.

> I can provide a GPU devcoredump from a future occurrence (I have a
> capture hook in place to copy it out before the ~5 minute expiry) if
> that would be helpful, and I'm happy to test patches or gather
> additional data.

I recommend you to open an issue here:
https://gitlab.freedesktop.org/drm/amd/-/work_items
Please give me a link to the issue you've created and let's continue the 
conversation there.

Thanks & best regards,
Timur