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.
But I hope 6.14.4 already solves the case!