Facing this issue on my Framework 13 with an AMD Ryzen 7 7840U w/ Radeon 780M Graphics (16).
Updating to the proposed kernel (6.14.3-300.fc42.x86_64) unfortunately didn’t fix anything. Switching to KDE Plasma seemed to stop the freezing, so this seems like the GNOME desktop on Fedora 42 is pretty badly broken. It was locking up pretty quickly, often within 10 minutes of boot, although sometimes it took as long as an hour.
Matt : are you using your computer in “balanced” power mode ? Seems to reduce the issue compared to Performance/PowerSave.
After you reboot, please use journalctl --list-boots to see your boots. The lower in the list, the most recent.
Then copy the ID and feed it to : journalctl -b boot-id
Then press shift-G to go to the end of the log and look around for the RED LINES and tell us what you see that is related to your amdgpu.
I’m running Fedora 42 and installed kernel 6.14.3 and been able to use the laptop for about two days without any issue (my amdgpu tends to crash and screen to die after 10-11 hours of continuous use).
Do you have that kind of error in your log :
[drm] ERROR flip_done timed out
?
Don’t know if anyone tried this yet, but for me on F40, it was necessary to disable PSR:
Add “amdgpu.dcdebugmask” to /etc/default/grub
GRUB_CMDLINE_LINUX="amdgpu.dcdebugmask=0x10 ..."
Then
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
And reboot
This disables Panel Self Refresh (PSR) which seems problematic in some AMD GPU - laptop screen combinations, working on an external screen through a docking station was fine. Downside is less battery runtime but such is Linux life…
Out of six sets of logs I sampled from yesterday where my laptop hung:
flip_done timed out messageamdgpu 0000:c1:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic dataAll of the logs also include: ERROR: NAME_CONFLICT: new_policy_object(): 'docker-forwarding' at some point, although I don’t know if that’s relevant or not.
Most of these are using the updated kernel, and died in less than an hour of booting.
I tried disabling PSR based on a tip from the Framework forums relating to X11 (not Wayland) desktops, but that didn’t do anything, unfortunately. I previously was running Fedora 40 and Fedora 41 on GNOME + Wayland without issues; the hang only appeared in Fedora 42.
I am indeed using my laptop in “Balanced” power mode, and that doesn’t appear to help or change anything.
Also worth noting that I haven’t seen this happen (yet!) with Fedora 42 using GNOME on X11: this seems like a GNOME-on-Wayland specific bug. Although since GNOME-on-Wayland is the default, that seems fairly bad… And it seems like touchpad gestures aren’t implemented on GNOME 48 with X11, so it’s a pretty annoying downgrade.
Sigh, that means no F42 for me yet as this is my daily driver/work laptop. Keeping an eye on this thread and hoping a solution gets found.
Here’s another instance from the Framework forums of someone having amdgpu-related issues with GNOME on Wayland with Fedora 42. They mention it seems to happen when they alt-tab? Alt+tab induced crashes on FW13 AMD Ryzen 7040 Fedora 42 (amdgpu bug) - Linux - Framework Community
The journalctl logs they share are:
Apr 25 18:04:54 fwrk kernel: amdgpu 0000:c1:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data Apr 25 18:04:54 fwrk kernel: amdgpu 0000:c1:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data Apr 25 18:04:54 fwrk kernel: amdgpu 0000:c1:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data Apr 25 18:04:54 fwrk kernel: amdgpu 0000:c1:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data Apr 25 18:05:04 fwrk kernel: amdgpu 0000:c1:00.0: [drm] ERROR [CRTC:79:crtc-0] flip_done timed out
I have edited my /etc/default/grub to add this to the kernel options :
GRUB_CMDLINE_LINUX=“rhgb quiet acpi.ec_no_wakeup=1 amdgpu.runpm=0”
the amdgpu.runpm=0 turns off the power-saving part
might be related to the flip_done issue that gets stuck in a timeout and kills the display and gpu.
Thanks. Gonna try to add this.
I see now at least three different bugs in this topic, and one phenomenon (including at least one of the bugs mentioned here) has definitely been solved by 6.14.3.
It is no longer comprehensible what belongs to where, and I therefore suggest to maybe open a new topic for post-6.14.3 issues, in order to allow supporters and (in case of a bug report) the maintainers to differentiate the remaining issues from those solved by 6.14.3.
Also, keep in mind that especially kernel issues can be very complex, and the logs of the very moment you experience the issue can be just symptoms (so the major indicator might be logged in the journal long before the time of the experience). Therefore, if you open a new topic, I suggest to add two things:
First, an extract of the very moment (so about the very moment plus at least 15 seconds before and after), but not just with -k (that is kernel-only entries) but from all logs . E.g., get the extract of the very times from sudo journalctl --no-hostname --boot=0 (if you had a full freeze or so, and need to get the logs of a previous boot and not the current one, use -1 instead of 0 → -1 implies the last boot, not the current one)
→ please use a codebox for this (the </> button)
→ also, feel free to further anonymize the content if there are still things contained you consider private or so
Second, at the full log of the kernel: sudo journalctl -k --no-hostname --boot=0 (as before, -1 instead of 0 if the last boot is needed instead of the current one).
→ you might use an external link for that or so
That said, you might want to wait for 6.14.4, which is already released and thus is likely to end up in bodhi soon and in your updates soon later. If that doesn’t solve your issue, open a new topic as suggested, and maybe already a bug report: if you open a bug report against kernel, please read the template carefully (once you click on the component kernel in bugzilla, a template will be automatically added to the report): consideration of the bug report is likely only if the template is filled correctly. Also, add the logs I mentioned. And of course: before creating a new kernel bug report, check out the existing bug reports that have been added since the release of 6.14 → if there is already one that describes your issue and that has then not been solved by 6.14.4, you might just add your case there → the more comes together in one report, the better the chances are to get it solved soon rather than having many different reports of the same thing.
Oops, I made a new post at the same time as @notafoe: Consistent screen freezes/hangs on Fedora 42 for AMD laptops using GNOME+Wayland
I think my post is more detailed so I’ll leave it up!
Might take my post down if possible, your one is better and makes mine redundant
I’ve been updating as able via the GUI Software app, as well as staying a step ahead on the kernels as instructed in this thread. Currently on kernel 6.14.4. Since updating via the GUI on Thursday 4/24 morning, I have only experienced one freeze, so F42 seems to be much more stable for me now.
Hello, sorry for the late response; I had read this was fixed but I still have his issue. I have noticed it is always when I am doing something on Firefox.
I can play for hours without a single issue, or coding; playing with VMs… not a single crash but as soon as I start doing something on Firefox, eventually, it will hangs.
Most of the time I can "un"hang it switching sessions, but there are times I have to power off the PC.
I was having the same issue. Gnome + Wayland + AMD gpu. I even tried reinstalling the OS. Eventually had to go back to Windows 11 for now. I have two monitors, and one time when it froze, the main monitor was completely frozen, but I could still move the mouse on the second monitor. I couldn’t use the mouse for anything though I couldn’t click, just move it around. I would also have to power off the PC.
Happens to me too with a fresh install of Fedora 42.
Amd 780M, AMD Ryzen 7 8845HS, gnome, wayland .
My laptop screen freezes, can still hear audio, had to hard reboot it to recover.
Did not try waiting 2 mins yet as suggested
Interestingly it also happened when I used an extra monitor, in this case the Laptop display froze completely. Could still move windows from it using Super key + arrow keys, to my external display. However it quickly made everything unstable and I had to hard reset it again.
Please use the following option to your kernel :
amdgpu.dcdebugmask=0x10
Will turn off the PSR. Please tell us if it helps.
Will let you know after it crashes again. Because somehow it seems that I have been spared by putting it on Balanced mode instead of performance
Might be related based on the log entries I see above (and which I have myself when a freeze occurs, but I experience the issue only seldomly): Making sure you're not a bot! → you might compare your logs when the full freeze occurs to the entry in the known bug.
→ 6.14.8 is on its way: FEDORA-2025-afd66770b7 — bugfix update for kernel — Fedora Updates System but it seems not to contain a dedicated fix about this, but let’s see.
To compare with mine, these can be seen in my last posts in the 6.15.6 page → FEDORA-2025-9bd55a2497 — bugfix update for kernel — Fedora Updates System , but the kwin_wayland_drm entries are specific to KDE and might not occur at GNOME, it is the amdgpu 0000:04:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data that is in common to the issue (if it is one)
→ if anyone can verify that they had this very issue with these very log entries already at earlier kernels, feel free to let the maintainers know, that might help to identify the issue. I have it only seldomly, and it seems above that some people experienced that already long before I saw it the first time
I want to share a solution that really helps me when GNOME Shell hangs on Wayland, but the keyboard and the system as a whole still works (for example, you can switch TTYs or hear notification sounds, but the interface is stuck and unresponsive).
What to do:
Ctrl + Alt + F3 to go to the text console (TTY).Ctrl + Alt + F2 to go back to the graphical session.
After that GNOME Shell “wakes up” and everything starts working as usual - windows move again, the interface is responsive, and the freezes disappear.
No reboot, no session logout, no data loss.
Why it works:
GNOME on Wayland sometimes gets stuck due to graphical/rendering glitches, but switching to another console forcibly updates the graphical context.