The game runs completely stably with -dx11 launch option. The crash is 100% reproducible on DX12 and 100% absent on DX11, conclusively isolating the bug to vkd3d-proton's DX12 translation layer.

Thanks for the feedback. I'm just trying whatever I can find. I don't know what I'm doing.

I am now on Proton-experimental. I've also removed the custom kernel flags and cleared the shader cache. It is still crashing in battle and while walking around.

I have tried both linux 6.12 and 6.18.

Here is my steam log.

steam-1903340.log

And here are the relevant errors from journalctl

crash.txt

I did eventually run into the same error with -dx11, although it seemed way more stable to me.

@raphaelcervantes Could you provide the following three things:

1. You haven't mentioned the specific Mesa version, which is very critical. Use vulkaninfo | grep driverVersion.
2. The specific version of your game: (1) Standard Edition (2) Digital Deluxe Edition (3) Expedition 33 x Metaphor: ReFantazio (4) Expedition 33 + Sifu Bundle (5) Expedition 33 + Windblown Bundle.
3. Your most recent save file at the crash point.
   I am investigating kernel memory management issues in #2881, and maybe this amdgpu: [gfxhub] page fault will be helpful to me.

@mengchenli1980 Thank you for this
1.
vulkaninfo | grep driverVersion  ✔ 
driverVersion = 26.0.5 (109051909)
2. Standard
3. It pretty much just crashes randomly, but usually in combat after 30 minutes of gameplay.

I found my save file, but the fileformat is not supported

I'm experiencing similar symptoms in Clair Obscur: Expedition 33 but with a different root cause.

My crash is: E_INVALIDARG on CopyCommandList->Reset(*NewCommandAllocator, nullptr) at D3D12CommandList.cpp:264, reported in #2978.

Hardware: RX 9060 XT (GFX1200), GE-Proton 10-34, Mesa 26.0.6, CachyOS.

Both issues may share a common origin in how vkd3d-proton handles UE5's D3D12 command list management. Mentioning this in case it helps correlate the two bugs.

@raphaelcervantes @Tigusigalpa272 Could you provide your most recent save files at the exact crash point?Since these bugs (especially the E_INVALIDARG and Page Fault) are likely tied to the game's specific environment. This includes screen settings, image quality levels. Therefore, besides the save files, the configuration files are also required. please package the entire users directory (which includes both saves and config files) into a tarball using the following command:

tar -zcvf expedition33.tar.gz
~/.steam/debian-installation/userdata/<your_steam_id>/1903340
~/.steam/debian-installation/steamapps/compatdata/1903340/pfx/drive_c/users

Also, could you provide detailed instructions on how to reproduce the crash from that save point, such as which specific battle to enter or what specific actions trigger the issue?

I'm traveling now. could do it after the weekend.
also, the crashes almost always occur in battle and usually happen when there are a lot of particle effects. but i would otherwise have trouble replicating it consistently. I'll see what I can do though

I just played about 3 hours today without it crashing on complete vanilla settings (no launch options, no kernel parameters). I was on proton-experimental and on medium settings.

The fact that "completely vanilla" + proton-experimental is stable suggests that those extra launch options or GE-specific patches might have been the trigger. If anything comes up later, feel free to send me your save and config files, and we can continue troubleshooting anytime.

I ran into the same error again. I'm attaching the journalctl file.

crash.txt

I was fighting the Paintress and the game crashed while performing Verso's End Bringer. The picture froze, but the music kept playing until it eventually went to black.

Mesa was recently updated driverVersion = 26.0.6 (109051910)

I'm also installing tarball of my e33.

expedition33.tar.gz

And another crash almost immediately doing a basic attack.

@raphaelcervantes Your logs are very helpful, thank you. This time it's not a page fault, but it could be a contributing factor. The main problems are three critical errors, causing the GPU to reject any further command submissions:

1.SMU (System Management Unit) error: "I'm not done with your previous command." The GPU power/frequency management firmware is stuck and cannot process basic instructions like "disable gfxoff."
2.MES (Micro-Engine Scheduler) error: "MES failed to respond to msg=MISC (WAIT_REG_MEM)." The firmware responsible for scheduling tasks has become unresponsive.
3.DMCUB (Display Micro-Controller) error: "DMCUB error - collecting diagnostic data." This indicates the display has frozen or gone black.
There is also an important amdgpu dump:
AMDGPU device coredump file has been created
May 04 19:47:49 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: [drm] Check your /sys/class/drm/card1/device/devcoredump/data

If the crash happens again, please run:
sudo cat /sys/class/drm/card0/device/devcoredump/data > ~/gpu_crash_dump.log
This file contains the GPU register state and instruction stream. Could you package it and send it to me? I'm currently investigating the issue.

I have to reboot when it crashes like this. I wasn't able to find the devcoredump/data. but this time I got a new error. Also, there was a Steam update immediately before this attempt.

May 05 18:55:09 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:09 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:09 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:09 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:10 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:10 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:10 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:10 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:10 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:10 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:11 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:11 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:12 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:12 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:12 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:12 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:12 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:12 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:13 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:13 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:13 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:13 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:14 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:14 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:14 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:14 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:14 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:14 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:15 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:15 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:15 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:15 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:15 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:15 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:16 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:16 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:16 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:16 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:16 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:16 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:17 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:17 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:17 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:17 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:17 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:17 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:18 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:18 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:18 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 18:55:18 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: device lost from bus!
May 05 18:55:18 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: response:0xFFFFFFFF for index:18 param:0x00000005 message:TransferTableSmu2Dram?
May 05 18:55:18 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!

I ran into another error just on the game loading screen...

May 05 19:46:46 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Dumping IP State
May 05 19:46:51 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000029 SMN_C2PMSG_82:0x00000000
May 05 19:46:51 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to disable gfxoff!
May 05 19:46:57 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000029 SMN_C2PMSG_82:0x00000000
May 05 19:46:57 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 19:47:02 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000029 SMN_C2PMSG_82:0x00000000
May 05 19:47:02 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to disable gfxoff!
May 05 19:47:07 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000029 SMN_C2PMSG_82:0x00000000
May 05 19:47:07 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 05 19:47:12 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000029 SMN_C2PMSG_82:0x00000000
May 05 19:47:12 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to disable gfxoff!
May 05 19:47:18 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000029 SMN_C2PMSG_82:0x00000000
lines 949-1000/1000 (END)

This situation is more severe than before. Essentially, it is the same error as before: the SMU unit is hung. However, the log shows that your GPU has dropped off the PCIe bus (device lost from bus). It is not just a software hang: when a response of 0xFFFFFFFF appears, it means the kernel can no longer access the graphics card's registers at all. It could be triggered by software, eventually causing the GPU to overheat, or it could be that your case has insufficient cooling. Please check whether your power supply is adequate, then reseat the graphics card, and test again after it has cooled down. Rule out the possibility of physical connection failure under extreme stress. I am also reproducing the bug here using the same environment as yours.

The one time with the severe errors, it seemed like the gpu was seriously stuck at a high usage state as it was crashed, and the fans were working at maximum capacity.

I've reseated my graphics card a couple of times. My power supply is 850 W. It was a computer I got from the facebook marketplace, but I checked that none of the power cables are daisy chained.

The game overlays suggest that the gpu and cpu are around 60 C, which doesn't seem like it should cause overheating errors.

I have tried a few more times and have gotten different-ish errors.

May 10 191424 raphael-b550mpro4_mesa_1.26.0.6_.txt

I tried downgrading from mesa 1.26.0.6 to 1.26.0.5 and it was far more stable, but ultimately still crashed.

May 10 202644_on_mesa26.0.5_.txt

@raphaelcervantes I downloaded your game progress and game configuration, and used the exact same environment as you: GE-Proton10-34. For the mesa version, I tried 26.0.5, 26.0.6, and 26.1.0-dev. I used Verso and cast End Bringer 20 times. Then I reloaded the progress and cast it another 20 times. In total, I repeated this 60 times and tested for a whole day. I also encountered a large number of "Unhandled sample count 0" warnings, but I did not find any problems, and it did not trigger any GPU crashes. The hardware and kernel environments I used are:

1. A 5800U industrial board (with Vega 8, GCN architecture).
2. A desktop PC (RX 7600 8G, RDNA3 architecture).
3. Ubuntu22 gnome x11 desktop with kernel6.19.

Our graphics cards are the same, both are RDNA3 architecture, only the VRAM size is different, so the radv logical processing should be the same. Therefore, this page fault issue should not be a universal problem. It might be an issue with your operating system and kernel version. If you have time, could you quickly install an ubuntu24, gnome with x11 or wayland, and see if the above page fault issue still exists in that environment?

@mengchenli1980 Thank you for looking into this with such great detail. I'm unfortunately too busy with work to install another OS at the moment. But I should have time over the weekend.

@raphaelcervantes Take your time. What I meant by this is that your previous operating system had too many variables. You added a bunch of kernel parameters and then removed them. The GPU hang might not be a rendering issue; it could be a display controller hang triggered by the swapchain, ultimately leading to a page fault and SMU hang. Therefore, the best approach is to use the cleanest system possible, install nothing, and add no parameters. Install directly from a USB drive using the Ubuntu 24.04 ISO, and do not install anything else after installation. Only install Steam, and finally install GE-Proton10-34. This kind of system is a minimal system, which eliminates interference from the operating system swapchain and kernel parameters. If running games and loading saves works fine under this system, then we can definitively rule out vkd3d-proton as the issue. The Ubuntu 24.04 kernel is new enough, so the only thing you could do is upgrade Mesa from 25.x. So, if you have time, could you install such a minimal and clean system to rule out the vkd3d-proton issue?

So I reinstalled Manjaro and haven't had any crashes since (probably about 4 hours of gameplay, including 3 bosses). I have a theory that my previous installation was problematic because I messed around with power management configurations trying to mitigate my bluetooth/wireless dongle from dropping.

Makes me never want to use an LLM to troubleshoot again.

@raphaelcervantes Thanks for the feedback! Just as I suspected, this is not a vkd3d-proton rendering bug at all.The AI randomly suggested modifying the PCIe power management (ASPM) and AMDGPU's low-power/scheduling parameters (amdgpu.gfxoff=0, amdgpu.mes=0, pcie_aspm=off). This caused the GPU to suffer from insufficient power/voltage response during specific heavy visual effect transitions or swapchain refreshes, ultimately leading to a Display Controller Hang, which then cascaded into a page fault and hardware deadlock.This perfectly explains why your GPU previously "dropped off" the PCIe bus—due to the power state failure, the kernel could no longer access any of the GPU's registers. In essence, it is a power delivery/state issue combined with heavy swapchain animations causing the Display Controller to crash, rather than vkd3d-proton causing a rendering crash.

Since the issue is fully resolved and confirmed to be a system-side power configuration quirk rather than a translation layer bug, feel free to close this issue whenever you have a moment. Glad you got it sorted out!

Ok. so I ran into the same-ish crash again while in battle. I'll just keep an eye on things.

May 20 20:07:51 raphael-b550mpro4 kernel: BIOS-e820: [mem 0x00000000feb80000-0x00000000fec01fff] reserved
May 20 20:35:52 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to export SMU metrics table!
May 20 20:35:57 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000029 SMN_C2PMS>
May 20 20:35:57 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to disable gfxoff!
May 20 20:36:02 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000029 SMN_C2PMS>
May 20 20:36:02 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to set workload mask 0x00000001
May 20 20:36:02 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: (-62) failed to disable fullscreen 3D power profile mode
May 20 20:36:08 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000029 SMN_C2PMS>
May 20 20:36:08 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: [SetDfCstate] failed!
May 20 20:36:08 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: Failed to disallow df cstate
May 20 20:36:08 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
May 20 20:36:10 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
May 20 20:36:16 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
May 20 20:36:16 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
May 20 20:36:16 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
May 20 20:36:17 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
May 20 20:36:17 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
May 20 20:36:17 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
May 20 20:36:29 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: MES failed to respond to msg=REMOVE_QUEUE
May 20 20:36:29 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: failed to unmap legacy queue
May 20 20:36:32 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: MES failed to respond to msg=REMOVE_QUEUE
May 20 20:36:32 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: failed to unmap legacy queue
May 20 20:36:35 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: MES failed to respond to msg=REMOVE_QUEUE
May 20 20:36:35 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: failed to unmap legacy queue
May 20 20:36:37 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: MES failed to respond to msg=REMOVE_QUEUE
May 20 20:36:37 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: failed to unmap legacy queue
May 20 20:36:40 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: MES failed to respond to msg=REMOVE_QUEUE
May 20 20:36:40 raphael-b550mpro4 kernel: amdgpu 0000:07:00.0: amdgpu: failed to unmap legacy queue
~

I still highly suspect this is caused by an issue with your power management module:

1. Failed to disable gfxoff and failed to disable fullscreen 3D power profile mode indicate that when the graphics card switches power states at an ultra-high frequency between low-power downclocking (gfxoff) and full 3D rendering mode (fullscreen 3D power profile mode), the power management response is delayed, causing the internal power management chip (SMU) of the GPU to hard lock.
2. The SetDfCstate failed error shows that before the crash, the mainboard PCIe link bus node rejected the GPU's power adjustment request. Although your RX 7600 XT is a mid-to-high-end card with a standard power consumption around 190W, the RDNA3 architecture can experience transient power spikes spiking up to 280W - 300W instantly when switching to high-load 3D mode. Even though your power supply's total rated wattage is enough, it might be that your motherboard firmware is too old, or the motherboard PCIe power scheduling compatibility is poor, leading to a delayed voltage response in such a short time, which causes the SMU chip to lose connection.

If you have time, could you try the following operations:

1. Update the linux-firmware package: This package contains the latest SMU firmware binary files for AMD GPUs, and the new version might have fixed known bugs in the internal GPU power scheduling.
2. Disable PCIe ASPM in the motherboard BIOS: This prevents the motherboard from actively lowering the power state of the PCIe link during game scene transitions or brief instant GPU idles, which can greatly improve link stability.
3. It is also possible that some power management scripts inside the Manjaro OS are interfering with the GPU state in the background, which has nothing to do with the game rendering itself. If possible, I suggest a clean installation of a standard, minimal Ubuntu 24.04 from a USB drive to test and completely rule out interference from Manjaro OS

I've just installed Ubuntu and now I somewhat frequently crash, but the error logs look much different. I've attached them.

I've updated my linux-firmware the most I can. I am on Ubuntu 26.04 LTS. The kernel is 7.0.0-15-generic
.

The LLM tells me there is a mismatch between the SMU driver and firmware, but everything is up to date as for as I can tell.

ASPM is off.

I'm also if this motherboard is so crappy it can't handle the load.

crash_journalctl.txt
dmesg_05222026.txt

Thanks for your feedback. Your kernel log is extremely critical, and it completely confirms my previous deduction: your B550M Pro4 motherboard has reached its physical limit, and it cannot even complete basic initialization normally.

Issue 1: Non-fatal error.
[ 19.996927] amdgpu 0000:07:00.0: smu driver if version = 0x00000035, smu fw if version = 0x00000040, smu fw program = 0, smu fw version = 0x00525f00 (82.95.0)
[ 19.996931] amdgpu 0000:07:00.0: SMU driver if version not matched
[ 20.043424] amdgpu 0000:07:00.0: SMU is initialized successfully!
This is because you eagerly used the extremely aggressive Ubuntu 26.04 and Linux kernel 7.0.0, which are still under development. In this extremely new kernel branch, AMD's open-source driver code modified the data structure for communicating with the SMU, while the graphics card's firmware has not aligned with it yet, causing the driver to directly throw "not matched". But this is not the main problem. "SMU is initialized successfully" shows that the SMU firmware has been successfully initialized, so this issue is not the reason why the GPU hung and died.

Issue 2: Fatal Issue 2: REG_WAIT timeout - optc32_disable_crtc (Hardware-level disaster)
[ 20.458920] amdgpu 0000:07:00.0: [drm] REG_WAIT timeout 1us * 150000 tries - optc32_disable_crtc line:195
[ 21.031453] amdgpu 0000:07:00.0: [drm] REG_WAIT timeout 1us * 150000 tries - optc32_disable_crtc line:195

In the Linux kernel DRM driver, the general framework order is: gem object -> plane -> crtc -> encoder -> connector. The CRTC is an important unit that controls cathode-ray tube timing, and for example, the vblank signal is sent by this unit. The kernel driver sent a shutdown command to the graphics card's register through the motherboard's PCIe bus, and then the driver used the REG_WAIT mechanism to wait. It checked whether the register returned a "success" state every 1 microsecond, and it literally waited for 150,000 times (which is 150 milliseconds, exactly 10 vblank signal cycles, delaying 10 frames). This shows a serious problem: the underlying communication between the motherboard and the graphics card (through the PCIe channel) has already caused packet loss and hard timeout because of electrical signal delay, unstable voltage, or signal reflection interference. The hardware has delayed its response for 10 frames, which belongs to a fatal mistake at the hardware level.

Issue 3: Kernel core fatal error caused by Issue 2: INFO: task kworker/... blocked for more than 122

Workqueue: ttm ttm_bo_delayed_delete [ttm]
May 22 19:38:11 raphael-cervantes-B550M-Pro4 kernel: Call Trace:
May 22 19:38:11 raphael-cervantes-B550M-Pro4 kernel:
May 22 19:38:11 raphael-cervantes-B550M-Pro4 kernel: __schedule+0x2b2/0x630
May 22 19:38:11 raphael-cervantes-B550M-Pro4 kernel: schedule+0x27/0x90
May 22 19:38:11 raphael-cervantes-B550M-Pro4 kernel: schedule_timeout+0xcf/0x110
May 22 19:38:11 raphael-cervantes-B550M-Pro4 kernel: dma_fence_default_wait+0x1a0/0x280
May 22 19:38:11 raphael-cervantes-B550M-Pro4 kernel: ? __pfx_dma_fence_default_wait_cb+0x10/0x10
May 22 19:38:11 raphael-cervantes-B550M-Pro4 kernel: dma_fence_wait_timeout+0xb6/0x180
May 22 19:38:11 raphael-cervantes-B550M-Pro4 kernel: dma_resv_wait_timeout+0xc8/0x1d0
May 22 19:38:11 raphael-cervantes-B550M-Pro4 kernel: ttm_bo_delayed_delete+0x2c/0xc0 [t

The Linux kernel has a dedicated daemon thread responsible for monitoring all system tasks. If a task enters an uninterruptible deep sleep and does not have any movement for more than 120 seconds, the kernel will judge that this task has deadlocked and alarm crazily. The 150 milliseconds of no response at the hardware level above triggered this kernel alarm. The Fence signal in the game has bitterly waited for more than 120 seconds, which means bitterly waiting for the vblank signal for 2 minutes. The graphics card hardware or its power management module/display controller had physically lost power at that instant. Essentially speaking: it is caused by your motherboard being relatively low-end and not matching the mid-to-high-end graphics card.

My suggestions:

1. Change to a good motherboard, and see from the forums what motherboard models are relatively matching for the RX 7600 XT. I do not suggest changing the graphics card, because if your motherboard is a low-quality motherboard, and the motherboard's wiring or power supply capacitors have defects, then changing to a low-end graphics card will also show common errors.
2. The most recommended method: force downgrade the PCIe rate from Gen 4 to Gen 3 in the BIOS. Because many low-end motherboards have too long wiring, are easy to generate inductance, and have poor anti-interference, they can easily cause bus disconnection due to signal degradation under Gen 4 high-frequency electrical signals. Trying to drop to Gen 3 should be able to improve stability.

You can try Ubuntu 24.04. The kernel of Ubuntu 26.04 is too new and might be too aggressive, which makes it easier to trigger bugs. Trying to use Ubuntu 24.04 might be more stable.

I've just installed Ubuntu and now I somewhat frequently crash, but the error logs look much different. I've attached them.

I've updated my linux-firmware the most I can. I am on Ubuntu 26.04 LTS. The kernel is 7.0.0-15-generic .

The LLM tells me there is a mismatch between the SMU driver and firmware, but everything is up to date as for as I can tell.

ASPM is off.

I'm also if this motherboard is so crappy it can't handle the load.

crash_journalctl.txt dmesg_05222026.txt

I came up the same "error" told by LLMs to you about SMU version mismatch. Also, tried ASPM off in bios and kernel options, and hole of other options. https://github.com/HansKristian-Work/vkd3d-proton/issues/3004

@sebadamus I do run into these issues. I largely mitigate them by capping the framerate to 60 fps and keeping the settings on medium-ish. But this is annoying.

@sebadamus I do run into these issues. I largely mitigate them by capping the framerate to 60 fps and keeping the settings on medium-ish. But this is annoying.

Its strange, but dont really know where the problem is because I lack enough knowledge.

Installed Kubuntu 26 .04 today and the SMU version mismatch is just the same, so I tend to think that message is only annoying.

I can tell that I mostly test in 60fps capped and max settings on everything and get the freeze anyway. Now I am in 6.17.0-35-generic and seems stable, but have tried too many stuff lately that cant be sure, will post back if I discover something else.

@sebadamus @raphaelcervantes The new kernel error logs (REG_WAIT timeout and ttm_bo_delayed_delete causing kworker to block for more than 122 seconds) are completely consistent with my previous analysis, which reconfirms the nature of the issue.

1. Capping the framerate to 60 FPS and lowering the graphics settings to medium successfully mitigated the crashes. This directly proves that the crash is highly correlated with GPU transient power spikes or high-load data transmission on the PCIe bus. Lowering the graphics quality and framerate reduces the burst throughput, thereby allowing the motherboard and graphics card to avoid the physical electrical crash threshold. The physical electrical limit of the motherboard (trace anti-interference capability or transient power delivery response) is likely the core issue. As I said earlier, dropping PCIe to Gen3 should be able to solve this problem.
2. The system became stable after rolling back to an older kernel (Kernel 6.17 series). This explains that the extremely new kernel in Ubuntu 26.04 is very aggressive in RDNA3's dynamic power scheduling (GFXOFF/voltage switching), becoming the last straw that broke their fragile hardware.
3. I still recommend installing Ubuntu 24.04 and upgrading Mesa to the latest version, which ensures that an aggressive kernel is not used.

@sebadamus @raphaelcervantes The new kernel error logs (REG_WAIT timeout and ttm_bo_delayed_delete causing kworker to block for more than 122 seconds) are completely consistent with my previous analysis, which reconfirms the nature of the issue.

1. Capping the framerate to 60 FPS and lowering the graphics settings to medium successfully mitigated the crashes. This directly proves that the crash is highly correlated with GPU transient power spikes or high-load data transmission on the PCIe bus. Lowering the graphics quality and framerate reduces the burst throughput, thereby allowing the motherboard and graphics card to avoid the physical electrical crash threshold. The physical electrical limit of the motherboard (trace anti-interference capability or transient power delivery response) is likely the core issue. As I said earlier, dropping PCIe to Gen3 should be able to solve this problem.

2. The system became stable after rolling back to an older kernel (Kernel 6.17 series). This explains that the extremely new kernel in Ubuntu 26.04 is very aggressive in RDNA3's dynamic power scheduling (GFXOFF/voltage switching), becoming the last straw that broke their fragile hardware.

3. I still recommend installing Ubuntu 24.04 and upgrading Mesa to the latest version, which ensures that an aggressive kernel is not used.

Since about 15 days, have been playing randomly for about 4/5 hours sessions... sometimes lefting the game alone (i.e. in DL The Beast it used to freeze just waiting at night where seems to be a lot of lighting transitions)

This is what I applied, mostly... reading tons of posts everywhere I could. Maybe nothing have any utility but its stable now, might neet to test removing options to see which one makes the freeze come back.

In my motherboard BIOS I disabled an onboard USB module (chip ASM4242) I realized I didnt use, maybe it killed 2 USB ports that shares PCIE lanes (something to do? dont know)
GPU, PCIE fixed to GEN4 (instead of auto)
I have 1 nvme disk installed in the onboard port where it does not share lanes with GPU (each motherboard have some specific configuration, in my case is the nearest nvme connector to the CPU... if you have every nvme port connected PCIE might change from 16X to 8x, share lanes or dont really know how each mother works that out)
EXPO1 6000mhz (also tried 5600, but as it seems stable I set EXPO1 again)
GRUB_CMDLINE_LINUX_DEFAULT='quiet splash split_lock_detect=off amdgpu.ppfeaturemask=0xffffffff amdgpu.gpu_recovery=1 amdgpu.dcdebugmask=0x10 amdgpu.lockup_timeout=10000 amdgpu.noretry=0'
Changed GPU DigitalPort to the second one (used to be connected to the first near the motherboard)
GE-Proton 10-34 and 11-2

Here some extra driver versions, kernel, etc.
inxi -Gx
Graphics:
Device-1: AMD Navi 31 [Radeon RX 7900 XT/7900 XTX/7900M]
vendor: Sapphire NITRO+ driver: amdgpu v: kernel arch: RDNA-3
bus-ID: 03:00.0
Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 24.1.6 driver: X:
loaded: amdgpu unloaded: fbdev,modesetting,radeon,vesa dri: radeonsi
gpu: amdgpu resolution: 1920x1080
API: EGL v: 1.5 drivers: radeonsi,swrast platforms:
active: gbm,x11,surfaceless,device inactive: wayland
API: OpenGL v: 4.6 vendor: amd mesa v: PPA glx-v: 1.4 direct-render: yes
renderer: AMD Radeon RX 7900 XTX (radeonsi navi31 ACO DRM 3.64
7.1.1-070101-generic)
API: Vulkan v: 1.3.275 drivers: N/A surfaces: xcb,xlib devices: 2

Hope it continues stable! (update: it freezed again but took about 6 hours, so... no fix found)

@sebadamus 1. Glad to hear you achieved a stable gaming experience. It seems you had too many devices occupying your PCIe lanes, such as the ASM4242 chip. This is a high-performance USB4/USB bridge chip with very high overhead, which might have been consuming the PCIe bandwidth. When running Ray Tracing or high-bandwidth visual effects, the PCIe channel couldn't satisfy the GPU's demands in time, leading to signal reflection and packet loss.
2. The kernel parameter amdgpu.lockup_timeout=10000 is highly likely the critical factor here, as it extends the threshold for the GPU lockup determination. Previously, the driver would immediately judge the hardware as dead and force a reset (subsequently causing the illegal opcode crash) whenever it encountered a microsecond-level delay. Now, you have loosened the timeout duration to let the driver "wait a bit longer," allowing the hardware to get past that specific timing conflict.
3. I have now also installed Ubuntu 26.04 on my two hardware platforms to see if my setups encounter similar issues. If any questions arise in the future, we can discuss them together.

1

Damn, just got a freeze after about 6 hours (playing and idling) 👎 could recover restarting sddm so went back to desktop. Not stable yet unfortunately, but can live with it.

@raphaelcervantes @sebadamus I tested with same environment: GE-Proton10-34 + Mesa 26.0.6 / Mesa 26.1.3 + kernel 7.0.0-14. My OS is Ubuntu 26.04 with GNOME desktop (Xwayland surface). The hardware setups I used are:

1. A 5800U industrial board (with Vega 8 2G, GCN architecture).
2. A desktop PC (RX 7600 8G, RDNA3 architecture).

I loaded a previous game save and kept running the Painter boss fight; no issues were found during 2 hours of testing. Subsequently, I played for another 2 hours, left the game idling for 2 hours, and then played for 2 more hours, none of which triggered any problems. It is possible that my RX 7600 has lower power consumption, and the motherboard has better compatibility with it.