PC crashes when resuming suspension in Gnome 48

English Install/Boot/Login
1

Hi, I have upgraded both computers to Gnome 48 with the latest snapshot 20250318 and on both computers (amdgpu) when resuming the computer after suspending it, the system crashes. Regards

Graphics:
  Device-1: Advanced Micro Devices [AMD/ATI] Cezanne [Radeon Vega Series /
    Radeon Mobile Series] driver: amdgpu v: kernel
  Display: wayland server: X.org v: 1.21.1.15 with: Xwayland v: 24.1.6
    compositor: gnome-shell driver: gpu: amdgpu resolution: 1920x1080~60Hz
  API: OpenGL v: 4.6 vendor: amd mesa v: 25.0.1 renderer: AMD Radeon
    Graphics (radeonsi renoir ACO DRM 3.61 6.13.6-1-default)
  API: Vulkan v: 1.4.309 drivers: N/A surfaces: xcb,xlib,wayland
  API: EGL Message: EGL data requires eglinfo. Check --recommends.
  Info: Tools: api: glxinfo,vulkaninfo x11: xprop,xrandr
2

Without relevant informations hard to tell. But there are quite some bugreports with crashing amdgpu…
https://bugzilla.opensuse.org/show_bug.cgi?id=1239741
https://bugzilla.opensuse.org/show_bug.cgi?id=1239617
https://bugzilla.opensuse.org/show_bug.cgi?id=1239616
https://bugzilla.opensuse.org/show_bug.cgi?id=1239657

1 Like
3

Thanks for your answer. In my case it only happens when I upgrade to Gnome 48, not before. Regards

4

The bugreports hint that it is related to Mesa…

5

I just tried deleting the packman repository and updating Mesa to the official openSUSE repository and the problem persists in both Mesa (packman) and Mesa (opensuse).

6

When you read the reports (also the upstream one), you will see that it seems related to Mesa 25.

1 Like
7

@Vernius … you might consider trying this.

For the moment, open a file manager or jump to a command line. Switch to the “.cache” sub-directory in your /home/myusername/, then display the content of that .cache sub-dir, as below.

user@machine:~/.cache>  ll
...
drwx------ ...  Jan  6 11:58 mc
drwx------ ...  Aug 23  2024 mesa_shader_cache  <----
drwx------ ...  Aug 21  2024 mozilla
...
user@machine:~/.cache>

You’ll notice I’ve pointed out the “mesa_shader_cache” sub-dir. That’s what you’re interested in.
Log out of your DE user session (GNOME, I think?) and back to the graphical login screen.

Switch to the first (main) terminal console (typically CTRL ALT F1), then log into your account. (you do not want to be in a graphical session).
Now “cd ./.cache” and list the content to be sure you see “mesa_shader_cache”.

Okay, now rename it using the mv command:

user@machine:~/.cache> mv mesa_shader_cache mesa_shader_cache-backup

Using mv basically saves the original mesa sub-dir to a new name, in case you want to restore that original.

Now use the mkdir command to recreate the original mesa sub-dir:

user@machine:~/.cache> mkdir mesa_shader_cache

Now you have a fresh and empty mesa_shader_cache sub-dir.
Now log out of the terminal console and switch back to the Graphical Interface (I use CTRL ALT F2, but it could be F4 or F6, etc).

When you see the graphical login screen, log in as your user account and see how things work out.
BTW, if you now use a file manager and go to the ~/.cache/mesa_shader_cache sub-dir, you will see all of its content has been recreated afresh.

That whole process should take five minutes or less.

2 Likes
8

It’s unlikely that it is a cache issue, as this problem is reported over several linux distributions after update to Mesa 25. Before trying the above procedure, check the content of the named directory. It is empty on many machines. So nothing to delete…

9

Similar problem here, the screen stayed black after resume, but could in some cases be activated again by unplugging the second screen. Deleting the cache did the trick for me. Thank you!

1 Like
10

Same issue with me after updating to Gnome 48.After unlocked my laptop from suspension,the desktop becomes completely freeze.Mine was Amd Ryzen 5 and Amd integrated graphics.Don’t know what I need to attach for the troubleshoot.

11

Hello, Thank you for your reply. The proposed solution did not work. The mesa_shader_cache directory was empty before moving it. Regards

12

@gamehhh @Vernius if you press ctrl+alt+F1 can you get to a tty? If so then press ctrl+alt+F2 do you get back to the GNOME Desktop?

1 Like
13

Hi, When I pressed ctrl+alt+F1 I accessed a tty. To return to the graphical session (gdm) I had to press ctrl+alt+F6.

14

@Vernius and did that help?

15

No, the problem persists once you log in to Gnome 48. The mesa_shader_cache directory was empty before moving it to a backup.

16

@Vernius If you just blank the screen (set to one minute) and not suspend, do you see the issue and if so try the ctrl+alt sequence.

1 Like
17

Has worked for us in the past.
You might also check the Reply just after yours - worked for them.

It’s quite possible, the cache dir is configured to exist elsewhere… for example, these env-vars might be used (among other methods):

$XDG_CACHE_HOME/mesa_shader_cache

MESA_SHADER_CACHE_DIR

The cache can also be disabled

https://docs.mesa3d.org/envvars.html

18

The bugreports already hinted that it is no cache issue…

The directory is empty on all Tumbleweed machines i could find and use. No special configuration.

19

Hmm. On six of our machines, it’s there with content. Of course, we’re on Leap 15.6 vs TW. We are also on KDE Plasma.

However, the cache can be located elsewhere, as I show in my Reply a few moments ago. On some installs, the cache can be located in a system-wide location. It can also be disabled.

You wrote:

when resuming the computer after suspending it, the system crashes

Does “suspend” mean Sleep mode, or Hibernate mode?

1 Like
20

@hui … that’s not the Reply just after yours :slight_smile:

This one: