Desktop repeatedly freezing on Tumbleweed

Hey everyone,
I’ve freshly switched to trying Linux after having a trial run on a work laptop with Ubuntu and now I’m trying dual booting with Win 11 and OpenSuse Tumbleweed with Gnome on my own private laptop.
It’s smooth sailing so far, but unfortunately I’m having some troubles: every now and then, seemingly at random, the desktop completely freezes and I can’t do anything. I can’t move the mouse, I can’t open the terminal, can’t open or close anything. After a time period, which seems to vary wildly, everything returns to normal. I’ve read it could either be a problem with memory or the the video drivers.
I tried installing zram for getting enough swap and I have about 16 GB RAM physical, so I’m not sure how memory could be the problem.
Video drivers I installed just like it was told in the OpenSuse-Wiki (it’s an Nvidia though).
I’ve copied a journalctl report from my last freeze:

Sep 25 17:27:27 localhost.localdomain systemd[2379]: Queued start job for default target Main User Target.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Created slice User Application Slice.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Started Submitting pending crash events (file monitor).
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Cleanup lingering KCrash metadata was skipped because of an unmet condition check (ConditionPathExistsGlob=/home/hhashzhkhenh/.cache/kcrash-metadata/.ini).
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Submitting pending crash events was skipped because of an unmet condition check (ConditionPathExistsGlob=/home/hhashzhkhenh/.cache/drkonqi/sentry-envelopes/
).
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Started Daily Cleanup of User’s Temporary Directories.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Reached target Paths.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Reached target Timers.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Starting D-Bus User Message Bus Socket…
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Listening on Socket to launch DrKonqi for a systemd-coredump crash.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Listening on PipeWire PulseAudio.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Listening on PipeWire Multimedia System Sockets.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Starting Create User Files and Directories…
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Listening on D-Bus User Message Bus Socket.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Finished Create User Files and Directories.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Reached target Sockets.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Reached target Basic System.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Cleanup lingering KCrash metadata was skipped because of an unmet condition check (ConditionPathExistsGlob=/home/hhashzhkhenh/.cache/kcrash-metadata/*.ini).
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Reached target Main User Target.
Sep 24 17:27:27 localhost.localdomain systemd[2379]: Startup finished in 180ms.
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Created slice User Core Session Slice.
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Starting D-Bus User Message Bus…
Sep 24 17:27:28 localhost.localdomain dbus-broker-launch[2434]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored
Sep 24 17:27:28 localhost.localdomain dbus-broker-launch[2434]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Started D-Bus User Message Bus.
Sep 24 17:27:28 localhost.localdomain dbus-broker-launch[2434]: Ready
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Created slice Slice /app/gnome-session-manager.
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Reached target GNOME Wayland Session.
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Reached target GNOME Shell.
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Starting Monitor Session leader for GNOME Session…
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Starting User folders update…
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Finished User folders update.
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Reached target Session services which should run early before the graphical session is brought up.
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Started Monitor Session leader for GNOME Session.
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Reached target Tasks to be run before GNOME Session starts.
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Starting GNOME Session Manager (session: gnome)…
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Started Application launched by gnome-session-binary.
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Started Application launched by gnome-session-binary.
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Started Application launched by gnome-session-binary.
Sep 24 17:27:28 localhost.localdomain gnome-keyring-daemon[2531]: discover_other_daemon: 1
Sep 24 17:27:28 localhost.localdomain gnome-keyring-ssh.desktop[2531]: discover_other_daemon: 1SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
Sep 24 17:27:28 localhost.localdomain gnome-session[2509]: gnome-session-binary[2509]: GnomeDesktop-WARNING: Could not create transient scope for PID 2543: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with ID 2543>
Sep 24 17:27:28 localhost.localdomain gnome-keyring-daemon[2533]: discover_other_daemon: 1
Sep 24 17:27:28 localhost.localdomain gnome-keyring-secrets.desktop[2534]: discover_other_daemon: 1SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Started GNOME Session Manager (session: gnome).
Sep 24 17:27:28 localhost.localdomain gnome-keyring-pkcs11.desktop[2533]: discover_other_daemon: 1SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
Sep 24 17:27:28 localhost.localdomain gnome-keyring-daemon[2534]: discover_other_daemon: 1
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Reached target GNOME Session Manager is ready.
Sep 24 17:27:28 localhost.localdomain gnome-session-binary[2509]: GnomeDesktop-WARNING: Could not create transient scope for PID 2543: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with ID 2543 does not exist.
Sep 24 17:27:28 localhost.localdomain systemd[2379]: Starting GNOME Shell on Wayland…
Sep 24 17:27:28 localhost.localdomain systemd[2379]: GNOME Shell on X11 was skipped because of an unmet condition check (ConditionEnvironment=XDG_SESSION_TYPE=x11).

For my hardware:
16 GB RAM
NVIDIA Corporation GA107M [GeForce RTX 3050 Ti Mobile]
Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics]
11th Gen Intel® Core™ i5-11300H × 8
HP Pavilion Gaming Laptop 17-cd2xxx

Do you know what might be wrong? Or what else I should check?

Thanks ahead!

I would like to add that even I faced this on my openSUSE Tumbleweed but KDE edition on an AMD 3400G, 16 GB ram system. There were some random freezes. Sometimes for 2 seconds, sometimes for more. It was random like OP said so can’t pinpoint when this happens. Also I didn’t have this on every session for me, but it happened sometimes.
BTW @IMIAD, can you try by switching to Wayland from X11 and see if it happens there also. I forgot to check this.

Exactly :slight_smile:

So, the weird thing I today found out about is this: apparently, Gnome was already running with Wayland? Instead I could switch to Xorg, which I now did and it seems to be running smoothly (I’ve only tested today so that might change later on).
It seems, when I try to run Gnome in/with/through Wayland, it tries to use X11 anyway and that’s where the errors and freezes are coming from? Not sure how that happened…

Gnome was already running with Wayland?

wayland display server, plus vulkan renderer

It seems, when I try to run Gnome in/with/through Wayland, it tries to use X11 anyway

inxi -G can show which Wayland/Vulkan parts there are

to get around some Vulkan renderer issues on Wayland session:
GSK_RENDERER=gl ./nameofgtk4app

This could be a wayland issue as already said, but let’s not underestimate a fundamental flaw in Linux rarely talked about and that the kernel is optimized for server loads. Ie throughput. It is not optimized for desktop latency. That means that given sufficient I/O, any linux desktop will exhibit micro-freezes like this as the I/O throughput gets prioritized over other processes including your desktop.

You can tune it somewhat with the right parameters and minize occurrance, but with the current status of the kernel and bar some desktop optimizations in the kernel, you can never completely get rid of it.

And let’s face it, unless Linux gets some significantly increased desktop share, there is not much incentive to optimize for desktop vs server use for corporations that largely foot the bill on development.

The journal is from 17:27:27 to 17:27:28 so only 1 second and not capturing your freeze period.

Try to find that period and upload it here or to susepaste.org

1 Like

PREEMPT_RT and sched_ext (scheduling from userspace) are coming with kernel 6.12. With that, desktop Linux will have a set of tools that can control latency and jitter.

PREEMPT_RT wikipedia

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=baeb9a7d8b60b021d907127509c44507539c15e5
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88264981f2082248e892a706b2c5004650faac54

Do you have more information on this? I know very specific use cases for RT kernels, but I don’t understand yet how this can help the desktop use case. There seems to be a bit of buzz around PREEMPT_RT and I guess 20 years of development can do that, but I can’t seem to be able to find much explanation about this and why or for what it useful.

Hey everyone!
Just wanted to let everyone know that contributed to this thread, that my problem seems to be solved. I’ve gone without any longer freezing for more than a week now and neither X11 nor Wayland seem to be making any trouble any longer.

I wish I could say what I actually did, but as far as I can tell, it was just a matter of riding it out and updating my system. Nevertheless, I learned a lot through the communication here :slight_smile: Thanks once again!

Good to know your issue has been solved. I found on reddit that some other users were also having this issue, and the proposed solution was to disable, btrfs quota which can be disabled by, “sudo btrfs quota disable /”.
So just in case, if this problem ever returns you may try this. The downside of disabling this is apparently not being able to check snapshot size. I don’t know if there is anything else but disabling this, is safe.

Well SCX (sched_ext) is the new hotness. It’s separate from the RT work. Many of the articles about it mention game mode as a use case, which is intriguing considering a lot of the tech comes from the artist formerly known as Facebook and the artist currently known as Google, for server workloads. BPF, so called due to its prior career in packet filtering, is a kernel level VM, so that programs are statically verifiable and just a little nightmarish. With SCX, BPF is used to send scheduling programs to the kernel that are supposed to be safe to use due to the statically verifiable aspect. Anyway there’s a thriving cottage industry specializing in these BPF programs. And the gamemode scheduler is actually happening, so that’s nice. (I will admit that this particular scheduler sounds rather like a variation on the default EEVDF scheduler.)

PREEMPT_RT is interesting to me in part because of the historical milestone, in part because deterministic latency appeals to me. I suspect the traditional criticisms of RT aren’t really correct anymore, but I have to do experimenting in this area to back up that idea. But either way the history of RT forms a large part of the move away from the throughput-only model, which you rightly mentioned, to the current approach.

If you do, also make sure you have QGROUP in /etc/snapper/configs/root empty, otherwise it will get enabled again automagically.

@throttlemeister Thanks for letting me know.
I see that it’s like this,

# btrfs qgroup for space aware cleanup algorithms
QGROUP="1/0"

Should I remove the “1/0” part?
So, it would look like this,

QGROUP=“”

Can you clarify?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.