protonscr

radv/amdgpu: The CS has been rejected

vkd3dopen
HansKristian-Work/vkd3d-proton#2881 · opened 2026-03-15 by birdspider · updated 2026-04-28 · 5 comments · github
Bbirdspider 2026-03-15 github

UPDATE: valve's proton10 works fine, so I'm sticking to that

Software information

Playing Age of Wonders 4, not having played it since release, it basically every other round, be it in or out of combat the game freezes.

I tried in-game "driver bug workaround" setting, and with and without VKD3D_CONFIG=no_upload_hvv

I'm not sure if this a vkd3d-proton bug.

System information

  • GPU: 9070
  • Driver: Mesa 26.1.0-devel (git-5a84a6b775)
  • Wine version: GE-Proton10-32 (due to proton-experimental cursor flicker between os/game)
  • VKD3D-Proton version: 6c09870 (according to ge-protons 10-32 tag

various lines like

... Invalid resource alignment 0x1000 (required 0x10000).
... Invalid resource desc.
(and finally)
radv/amdgpu: The CS has been rejected, see dmesg for more information (-2).

there is no additional info in dmesg/journalctl.

However the only occurence in mesa is in

src/gallium/winsys/amdgpu/drm/amdgpu_cs.cpp
2121-      } else {
2122-         amdgpu_ctx_set_sw_reset_status((struct radeon_winsys_ctx*)acs->ctx,
2123-                                        PIPE_UNKNOWN_CONTEXT_RESET,
2124:                                        "amdgpu: The CS has been rejected, "
2125-                                        "see dmesg for more information (%i).\n",
2126-                                        r);
2127-      }

maybe PIPE_UNKNOWN_CONTEXT_RESET means something

Log files

steam-AOW4_2.log
steam-AOW4_1.log

AABJ4403 2026-04-11 github

Happen to me too on RAM-intensive games, but for me once the system recovers from the deadlock (yes it locks up the whole system) the game is unrecoverable, requiring force-restart of the game (and losing some progress)

Mmengchenli1980 2026-04-18 github
  1. From a code logic perspective, this error message does not come from mesa-26.1.0\src\gallium\winsys\amdgpu\drm\amdgpu_cs.cpp, because that is the Gallium layer path used by the OpenGL driver (RadeonSI). For RADV (the Vulkan driver), command submission goes through src\amd\vulkan\winsys\amdgpu\radv_amdgpu_cs.c, where the radv_amdgpu_cs_submit function contains the following error handling code:
    else { fprintf(stderr, "radv/amdgpu: The CS has been rejected, " "see dmesg for more information (%i).\n", r); result = VK_ERROR_UNKNOWN; }
  2. The error code -2 in the log corresponds to the macro ENOENT, whose standard meaning is "No such file or directory". This means that the kernel driver, while parsing the submitted command stream, found an invalid resource reference (for example, a buffer or GPU virtual address that does not exist). A reasonable speculation is: VKD3D-Proton, when handling resource requests from the game (in combination with the Invalid resource alignment warning in the log), may have constructed a defective command packet due to alignment issues. This packet may have passed preliminary checks in the RADV userspace driver, but was ultimately strictly rejected by the kernel driver, returning -ENOENT and causing the submission to fail.
  3. I am currently trying to reproduce this issue in my own environment, and plan to locate and fix it. I will update here when there is progress.
Mmengchenli1980 2026-04-23 github

@birdspider I’m currently investigating this issue and trying to reproduce the -2 CS rejection on my end. I'm using a same environment (GE-Proton10-32 Mesa 26.1-devel, v6.19 kernel), but so far, everything seems stable. Although I can see the same "Invalid resource alignment" warnings in my logs, the game doesn't crash
could you provide a save game file that is close to the crash point? Also, if you could mention the specific graphics settings or actions (e.g., zooming on the world map, entering a specific battle) that trigger the crash more frequently？

Bbirdspider 2026-04-26 github

@mengchenli1980 I did give it another go, reloading old savegames from the time the crashes happened. I clicked, hovered items, scanned/zoomed map, switched menus and moved armies and fought some battles. But could not reproduce it at this time.

regarding your point 2.

This packet may have passed preliminary checks in the RADV userspace driver, but was ultimately strictly rejected by the kernel driver, returning -ENOENT and causing the submission to fail.

It seems there were some updates in mesa/radv regarding packets - so this might already be fixed.

LC_ALL=en_US git lga 5a84a6b775..HEAD --grep pack -- src/amd/vulkan/winsys/amdgpu
b41cd597902 21.04.2026 15:02 <Qiang Yu> ac,radeonsi,radv: use V_581A_* engine sel for non-pws acquire_mem packet
a7c63ae6fa9 22.03.2026 00:22 <Marek Olšák> amd: switch to new packet definitions for all packets

I'm going to attach 2 (what I think) are savegame files from 16. March and some sort of debug.txt. (there also a bunch of empty AOWe0a3.tmp,AOWe0a3.dmp files I omit). Taken from ./compatdata/1669000/pfx/drive_c/users/steamuser/AppData/Local/Temp/

3417921f-700d-4a95-860e-92587b3ace7e.txt.gz some sort of dx12 diagnostic

746f62c8-e002-4a49-b125-656b3df909b8.tar.gz savegame-dir

a8d43397-0a05-46a0-b56c-19e19cbaf578.tar.gz savegame-dir

Mmengchenli1980 2026-04-28 github

@birdspider Thanks for the help and for testing the old savegames.
I have successfully loaded your save at Turn 74, performing combat and map zooming. Everything seems stable for now. It’s possible the current workload isn't enough to trigger the specific Page Fault that led to the GPU hang.
I have set up a full O0 debugging environment with GDB/KGDB to trace both RADV and amdgpu.ko. I plan to investigate exactly where the memory management might be failing

Proton versions

Launch options