Just want to contribute to this issue. I have had MES Ring Buffer issues while using certain apps on Fedora 43. My understanding is that there is a driver level issue with the Strix Point series.
Steps to reproduce: Download Komikuu flatpak and read your favorite comic (preferably really long ones)
Computer should start pulling a crazy amount of resources
Computer freeze
Run JournalCTL
Figured this information is likely useful to someone.
Experiencing this on both Fedora 43 and Ubuntu 25.10 - in my case it seems to happen more frequently when youtube is open in Google Chrome. Going to try switching to Firefox for a bit to see if that is more stable but the driver shouldn’t be crashing regardless.
My latest crash was caused by an AMD GPU hang triggered by Chrome.
The sequence:
Chrome’s GPU process caused a page fault in the AMD graphics driver (amdgpu)
The GPU’s graphics ring (gfx_0.0.0) timed out
The driver tried to reset the GPU but failed - MES failed to respond to msg=RESET
The GPU ring reset failed completely
Key error lines:
amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:5 pasid:32772)
amdgpu: Process chrome pid 4007 thread chrome:cs0 pid 4038
amdgpu: ring gfx_0.0.0 timeout
amdgpu: Ring gfx_0.0.0 reset failed
I think one problem is the “amdgpu: MES failed to respond…” message has a number of different causes.
For some causes, the amdgpu.sg_display=0 may help.
For others the amdgpu.cwsr_enable=0 may help.
or this one might just be something new.
Let me add my 50 cents to this; I think it’s not only a software issue but also hardware related.
I’m on an Asus Flow Z13, which I got as soon as they where available little under a year ago. I had the issues mentioned here, maybe once every 2-3 days. Annoying, but I figured firmware would be fixed at some point. Tried various boot parameters, with no real change to show for it.
Before New Years the laptop went in for RMA and when I got it back, they had replaced the motherboard. Now I’m having the issues as frequent as every 5 min. Making it almost unusable. Even if I roll back to a kernel and firmware from October or add all the suggested boot parameters. The issues remains.
The same kernel, firmware and laptop from last year, that crashed every 2-3 days, now crashes every 5 min. Only thing changed is the motherboard.
This indicates to me, that the issue is related to which batch/revision of GPU you have.
So we might have a situation, where the vendors and (AMD) developers are on a batch/revision that maybe never or rarely crashes and users might have one that crashes all the time.
Hence we’re seeing different solutions for different users and the real issue doesn’t get resolved.
I hope you’re wrong and you were just unlucky enough to get your laptop back after breaking change landed. I’m testing this patch now and god, I’m hopeful. Already running a workload that used to hand my laptop pretty quickly for over an hour already and its still stable.
It will take a while to get rid of the feeling that crash is about to happen when I click through web pages though.
Edit: nope. Still happens. I hope that it will fix the stability of system for at least few of you folks, I’m staying with my pretty expensive brick for now.
Get same issue here and I think it came after upgrading recently. Screen freeze while nothing special is done. I have this in logs:
Mar 18 12:34:18 fedora kernel: amdgpu 0000:c1:00.0: amdgpu: MES failed to respond to msg=MISC (WAIT_REG_MEM)
Mar 18 12:34:18 fedora kernel: amdgpu 0000:c1:00.0: amdgpu: failed to reg_write_reg_wait
amd-ucode-firmware-20260309-1.fc43.noarch Tue 17 Mar 2026 07:49:16 AM CET
amd-gpu-firmware-20260309-1.fc43.noarch Tue 17 Mar 2026 07:49:16 AM CET
kernel-6.19.8-200.fc43.x86_64 Tue 17 Mar 2026 07:49:15 AM CET
I’m running Fedora 43. I didn’t desactivate yet MES, does anyone else get recently the issue ?
Thank you Mario, not sure I’m enough advanced user to apply this kind of patch. Do you think it will be upstream soon ?
Maybe I should disable MES because it occurs often. I’m wondering if the trigger isn’t when I plugged the USB cable that share an additional screen.
I was filling the bug and notice that issue doesn’t appears back. I believed I enabled amdgpu.mes=0 amdgpu.sg_display=0 but noticed I forgot to generate grub config. So issue did not appear again without any change.
Is there a way to force the problem to happen ? in the bug form I should attach some logs and try to reproduce with development kernel.
I have personally never experienced it and as far as I’m aware no one else in AMD has been able to either.
The patch produced there is specifically generated based on what a bisect came down to. It’s code for future products that caused the regression so it’s narrowed down to only apply to the new features from future products.
I have the same issue for some time now, and followed advice from claude for kernel parameters, then i logged kernel messages while it happened, i did Claude also write a summary, so maybe this is helpful debugging it.
Edit: Well, maybe i should have read up more on the current status, seems like it is addressed in Linux 7.0, removing post, and only reference link to github issue here:
Ubuntu oem kernel seems to have acknowledge the bug and have a human assigned to it:
Until the fix is released people in the discussion report stable life using 6.17.0-1012-oem. I’ve only been on it for a few days but so far it does seem to help mitigate the bug.
As a side note, the fix is in -proposed linux-oem-6.17/6.17.0-1026.26. Look at the bottom here. I deployed the proposed kernel and haven’t had a single issue since.