I’ve been experiencing extremely frequent screen freezes on Fedora 42 with GNOME on Wayland ever since upgrading on my AMD Framework 13. Many other users have reported the same issue with AMD-based laptops. Upgrading to a newer kernel version as suggested — specifically, Linux 6.14.3-300.fc42.x86_64 — doesn’t fix anything, nor do various suggestions around disabling PSR, battery modes, etc.
There are a few threads on the Framework forums where users mention this:
Personally, the majority of the journalctl logs relating to crashes/hangs on my machine since upgrading to Fedora 42 have some amdgpu-related error, similar to the one listed above.
Since there are many different kernel/driver-related issues with crashes/hangs/performance problems with Fedora 42, please do not post crashes/hangs/perf issues in this thread that don’t relate to AMD devices with GNOME+Wayland. The previous thread on a similar topic had multiple different issues reported that conflicted with each other, some of which were solved by various kernel upgrades, disabling PSR, etc, but which didn’t solve the AMD+GNOME+Wayland issue.
Since the kernel is already in stable, it is not sure if the maintainer still reviews new posts there, but it might be worth a try to give the maintainer the possibility to become aware of it (if not already happened).
If you can test the next kernel early when it enters testing stage (so once it is in bodhi and a yellow-backgrounded dnf command is shown on the page - that yellow-backgrounded command usually shows up some hours or about a day after the page shows up), and then provide a feedback early in its then-existing bodhi page, including a link to your elaborations here (which then might also contain cases of others). That might give the maintainer early the possibility to become aware of the issue, but keep in mind the issues and considerations I mentioned about getting a new kernel as long as it is not pushed to stable here.
If you create a bug report, which might be a good idea if 6.14.4 does not solve the issue, you might also add the links you found on other pages about the case (beyond what I already elaborated in the other post about what to contain in a bug report and what to consider when creating one). Also, in a bug report, add links to upstream issues (such as the drm/amd case you seem to have already found) and other Linux distribtion issue tickets that are about the same case → helps to keep all available knowledge and data about the case together, and avoid double work, but also make clear if it is a wider phenomenon.
Also, I added the kernel tag as this is potentially/likely a kernel issue.
Unfortunately, I cannot invest much time the next days But I hope 6.14.4 already solves the case!
@gilbert-fernandes I saw you gave +1 karma (thumbs up) in bodhi in 6.14.3 → keep in mind that this implies that everything is fine. So your comment will not cause attention as the system does not mark it as “problem” case.
You should use thumbs down when there is a problem, so that it is logged correspondingly.
Also, keep in mind that a regression test is a specific test suite: I assume you didn’t do that. If that is the case, you can leave that field just neutral, and just give the karma.
General, the 6.14.4 is available now for testing (the yellow-backgrounded cmd is shown on the page of 6.14.4, as explained earlier), and several people already report it works fine. If you want the quickest and easiest chance for consideration without a bug report, testing before it gets pushed to stable is the best way: if several people elaborate their case with thumbs down, the maintainer might check it out if the cases seem to correlate to each other.
But generally: keep in mind that thumbs down in bodhi is for a new bug, not for existing ones. You might do that in 6.14.4 as you just found out that you have something different than the known case that was solved in 6.14.3 (and it is likely that your karma in 6.14.3 is no longer considered as it is already in stable). But if 6.14.4 does not solve the case, and if the negative karma ain’t sufficient, you might need to check for existing bug reports and add your data, and if none exist, create a new one (I already elaborated that in my last posts). Once that occurred, focus on the bug report and no longer on bodhi feedback.
Gave a thumbs up because the amdgpu freeze issue is not a kernel issue but upstream and located in the firmware that amdgpu does load. Will use thumbs down next time.
On my computer, yes.
I am using a Lenovo P16s Gen2 with 7840 + 780M (AMD)
Fedora, kernel 6.14.3-300.fc42.x86_64
which is the latest available (unless saying something stupid)
Since I added the following options to my kernel boot (/etc/default/grub) :
amdgpu.runpm=0 amdgpu.dcdebugmask=0x10
I have not suffered a freeze since yesterday, continous use.
Today I watched videos, went to Reddit and did a lot of scrolling + playing videos
Used the laptop all day long without a single freeze drop on me.
the qmdgpu.runpm prevent the power manager to disable the gpu internal core (from which it does not wake up, producing a timeout on the flip thing)
The other one I have since a long time because the laptop has issues with my LCD display. I’m using the low-power low blue light version of the panel, and it would turn off and not come back… so the dcdebugmask fixes this. I no longer have the LCD that turns off and never comes back on.
The acpi.ec_no_wakeup=1 is recommanded on some Lenovo laptops when they have trouble coming back from sleep.
A few days ago the amdgpu would die either after 5-10 minutes, a few hours, or over 10 hours of use at random. With the current kernel options, I’m over 12h of use over 2 days, with no issue.
This means the GPU will use a litlte more power though…
In Fedora 40 I didn’t reboot the computer for months until the amdgpu-firmware was updated in March. I had got several freezes amdgpu 0000:64:00.0: [drm] *ERROR* [CRTC:79:crtc-0] flip_done timed out, until I downgraded the firmware package and using the previous kernel. I upgraded to fedora 41 the last week and the freezes have become recurrent. So I reckon is a firmware issue and not only a fedora 42 issue if I am not missing something. I am in Lenovo P14s with 7840 + 780M (AMD), kernel 6.13.11-200.fc41.x86_64 and . amd-gpu-firmware.noarch 20250410-1.fc41. I will try amdgpu.runpm=0
Tangentially related, but I had this issue non-stop with Fedora 41 for months with a Lenovo Yoga Pro 7 (AMD Ryzen™ AI 9 365 w/ Radeon™ 880M) and it has been a good as gold since updating to 42
to the kernel parameters seems to work around this problem (although battery life definitely takes a hit as a result). Thanks @gilbert-fernandes for finding it
Haven’t tried isolating to just amdgpu.runpm=0 since the crashes were pretty annoying and I’m loathe to go back (they were happening within an hour of boot pretty consistently). Curious if anyone else wants to give it a shot though! IIRC when I tried amdgpu.dcdebugmask=0x10 alone I still saw crashes/hangs.
Override for runtime power management control for dGPUs. The amdgpu driver can dynamically power down the dGPUs when they are idle if supported. The default is -1 (auto enable). Setting the value to 0 disables this functionality. Setting the value to -2 is auto enabled with power down when displays are attached.
Because I was getting timeouts, I thought the GPU went to micro-sleep and never came back from it. So I went full hardcore on it and turned off the power save option of the whole gpu itself with this parameter.
On my laptop, instead of being between 0-3 Watts it doubles the GPU power use that goes from 6W to 10-12W.. But at least, no freeze. And since I’m mostly using the laptop with the power plug on…
I am glad I found this thread. I experienced this recently and was wondering if I am experiencing a hardware failure. Glad to know a kernel parameter can fix it for now and it is being investigated.
This issue is rather AMD related. But when you get a freeze on your Nvidia card, are you able to SSH into that machine to check if only the display is frozen ? (you will have to install and/or turn on the SSH access as default Fedora doesn’t do that). Do you have anything related to this issue in your system log ?
(you can list the previous boots and check the journal from those, one by one. If you dont know how, ask, it’s easy to learn)
I have 2 monitors. When one of them freeze (always the secondary (2) monitor fist), I can’t do anything in that monitor. But I still can use the other monitor (1). When both of them freeze, I can’t even turn the computer off by pressing the button or do anything.
I switched to Xorg for two days and did not happen again.
I upgraded to the last kernel (Linux 6.14.6-300.fc42.x86_64) this morning, and I’m not experiencing the freeze on Wayland anymore… at least for now. They added a fix for this problem, maybe?
I suggest to check out the logs of a broken boot (you can use sudo journalctl -r -k --boot=-1 to get the last boot, or -2 the one before the last, etc.). If you have no amdgpu error, you should open a new topic and presume it is something different: it is neither good for the documentation here nor for yours to merge two problems in one topic.
But generally: unless there is explicit indication that you have same problem as the user above (such as the same error logs or very same complex behavior, beyond just freezing screens), you should generally open a new topic anyway: the OP has not added posts for some time, so we have to assume their problem has been solved (we cannot verify if through a workaround or a permanent solution). If you open a new topic and think it could be related, you can create a link in your new topic to here. But that would be more transparent for helpers to see what relates to where: keep in mind that this topic is marked as solved, and therefore many people will not read new posts (which is a good reason to open something new in any case). Therefore, you will get likely less help than in a new topic.
Supplement: you should also add more information in your new topic… To know that you have nvidia does not suffice to know what problem you have. Logs, exact problem symptoms, fedora release+variant, third party repos/modifications, etc.
I’m in the same boat as you. We’ve had this a few times on the F41 and it’s frustrating. It’s the only thing I’m worried about having a problem with when it comes to the stability of my laptop, for example, at a customer’s place.
This has happened to me about 3 times today and it hasn’t happened in a long time. I’ve been on F42 for 4 days. And it does it very randomly.
Today I’ll try adding the parameter amdgpu.dcdebugmask=0x10 for the first time and we’ll see, I’ll let you know in time if it ever appears again.
But I hope 6.14.4 already solves the case!
