Help, Fedora 42 Randomly crashing when opening applications

Ask Fedora
, , ,
1

I have been installing Fedora 42 multiple times these past 3 weeks, and I am having a consistent crashing issue.

The problem, simply explained, is this:

Opening an application (especially GNOME applications) makes my system prone to crashing.

It’s especially prevalent whenever I crash (because of the apps), get thrown back to the login screen, log in again, and then open the same app again.

I have exactly two apps that aren’t GNOME applications (Zen Browser and Steam), and these two apps do not cause this issue.

At first, I thought perhaps the apps I installed through Flatpak were causing this issue, but that’s not the case. I’ve installed Console (gnome-console) through dnf, and it also causes a crash:

1000040916
10000409161920×1595 309 KB

Notice the visual artifact; it happens many times but not always.

Then I thought perhaps it was just my GPU. I bought a used GPU for this particular PC build, but when I tried installing Fedora KDE, this issue almost never appeared.

So I suspect there’s a problem with GNOME, specifically Mutter, and also perhaps Wayland.

I have attached the journalctl output in a text file for you to peruse. Also, here are some links provided by problem reporting apps that indicate the crash:

Crash log: Crash Log for reference · GitHub

This is my PC spec:

Screenshot From 2025-06-27 23-59-27
Screenshot From 2025-06-27 23-59-271102×762 73 KB

What I have tried to resolve this issue:

  • Uninstalling nvidia-gpu-firmware-20250613-1.fc42.noarch (not sure why rpgfusion for Nvidia exists on my system, as I’m using AMD). The problem kept appearing, so I re-installed it.
  • Installing Fedora KDE resulted in the problem being noticeably reduced, with rare crashes. However, once it crashes, I need to hard reboot.

Please help me.

2

Hi, I see from your journal: amdgpu: The CS has cancelled because the context is lost. This context is innocent. This means that the stack trace ABRT provided is unfortunately pointing to innocent code, and the easiest debugging techniques will not work. I think your GPU is resetting?

I searched the mesa issue tracker for related issues and only found this one which might be related.

1 Like
3

Buying used GPUs can be tricky. I would dare to say that if the price is very low, it is likely that the GPU is defective.

You should never experience any video or other corruption. If you do, there is clearly something wrong, and it is very likely a hardware issue.

I suggest testing each component. You can test your memory with MemTest86+. For the GPU, if you have a dual boot with Windows, you can try OCCT or OCBASE for CPU, memory, and GPU stress tests.

1 Like
4

Thank you for the reply.

Yes, I suspect the problem is related to GPU randomly resetting.

I checked the links and tried to do what cyklopvargen suggested by adding amdgpu.mcbp=0 to GRUB parameters.

I’ll check if it’s working.

(I also added rd.driver.pre=amdgpu previously to fix Plymouth not appearing properly (three dots) perhaps this also contribute to the problem?)

5

Thanks for the reply.

Yes, I suspected perhaps that it was just my GPU being defective, but the problem didn’t happen back when I was using Windows last month and almost never happened in KDE; so far this problem exclusively happening in GNOME for me, unfortunately.

I’ll make time to do Memtest, thank you.

6

I think I found the source of the problem.

Reading this thread: Constant freezes after suspend on Fedora 40 with AMD GPU (RX 6700 XT) - #5 by litemotiv

I follow the instruction to disable PSR:

sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover

…and my desktop immediately crash; so I can’t disable the parameter just yet, any suggestions?

7

I seriously doubt that your issue is caused by PSR, which is mainly used for battery savings on laptops. You can always disable it completely by booting with the amdgpu.dcdebugmask=0x610 kernel parameter. However, I have never seen PSR cause corruption like what you’re experiencing. I highly recommend that you stress test your hardware first to rule out any potential hardware problems.

8

The command in question doesn’t disable the PSR but it resets the GPU when it is stuck or showing glitches, so it could indeed make your session crash if the reset is unsuccessful.

The second part mentioned in the comment is to disable the PSR (the amdgpu.dcdebugmask kernel parameter). You can add that to your system without using the amd_gpu_recover command.

1 Like