(KDE) Taskbar frozen after waking from sleep

[Red_AM]

Waking from sleep almost always causes the taskbar to freeze. Either it’ll be unreponsive or some parts of the UI will be frozen or missing. In some cases the entire display output will fail (just a blackscreen, no lockscreen or anythign).

Here’s the logs for the last time it froze:
https://paste.cachyos.org/e556918.log

Will post logs again when the display output fails.

[cscs]

Just a guess .. but you might try doing the normal browser-extension test .. that is remove any extra add-ons you might have in the panel until its the defaults and observe the behavior then. Slowly add back in your third-party extensions until things are broken again and then you know what is to blame.

Similarly you might try a new user account for the same reasons.

Finally if you cant track it down exactly but it may be related to the current account .. you can always ‘reset’ the plasma settings by removing configs/cache. Be aware that performing this will mean you need to re-apply things like your themes and so forth.

https://wiki.archlinux.org/title/KDE#Configuration_related

[Red_AM]

I tried removing panel colorizer (the only plasmoid I added) to no success.

https://paste.cachyos.org/4a7abb2.log

So I ran these logs through Claude to see if it can pinpoint the issue and it seems to suggest it’s a bug with Nvidia drivers and Wayland? Here’s the chat log:

Plasma Desktop froze after waking from sleep. Can you pinpoint why that happened with these logs?

What Happened in the Logs

1. System Entered Sleep (Suspend)

[27227.784952] PM: suspend entry (deep)
...
[27228.062861] printk: Suspending console(s) (use no_console_suspend to debug)
[27228.537480] ACPI: PM: Preparing to enter system sleep state S3

2. System Woke Up (Resume)

[27228.865693] ACPI: PM: Low-level resume complete
[27228.903201] ACPI: PM: Waking up from system sleep state S3
[27228.905547] xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit
[27228.905550] usb usb1: root hub lost power or was reset
[27228.905552] usb usb2: root hub lost power or was reset
...
[27231.709263] Restarting tasks ... 
[27231.713620] done.
[27231.713633] random: crng reseeded on system resumption
[27231.713641] PM: suspend exit

3. Immediately After Resume:

• USB controller errors:

xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit

• Multiple USB device resets (mice, keyboard, audio, etc.)

• NVIDIA DRM error after next suspend/resume cycle:

[drm:__nv_drm_semsurf_wait_fence_work_cb [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002b00] Failed to register auto-value-update on pre-wait value for sync FD semaphore surface

4. KDE/Plasma Errors After Resume

• Wayland/KWin errors:

kwin_wayland[1420]: kwin_wayland_drm: atomic commit failed: Invalid argument

• Plasmashell QML errors:

plasmashell[1547]: file:///usr/share/plasma/plasmoids/org.kde.plasma.systemtray/contents/ui/items/PlasmoidItem.qml:208: TypeError: Cannot read property 'fullRepresentationItem' of null

• Notification manager and other QML errors

• Pipewire/ALSA errors (audio subsystem, not directly related to freeze but may indicate instability)

---

What This Means

• The freeze is triggered by a combination of:

• USB controller (xhci_hcd) failing to resume cleanly (common on some AMD/NVIDIA platforms)

• NVIDIA DRM/driver errors after resume, which can break graphics stack state

• Wayland/KWin atomic commit failures (graphics stack can’t reinitialize properly)

• Plasmashell QML errors (taskbar/system tray code can’t access expected objects, likely due to graphics stack issues)

---

Root Cause

The most likely root cause is a bug in the interaction between your NVIDIA driver, the kernel, and the Wayland session (KWin/Plasma).

• The USB controller error is a hardware/firmware or kernel driver issue, but it often doesn’t freeze the desktop by itself.

• The NVIDIA DRM error and KWin atomic commit failures are the most direct cause of the desktop freeze: the graphics stack can’t recover after sleep, so Plasma can’t redraw or respond.

• The QML errors in plasmashell are a symptom, not a cause: the UI can’t access the graphics resources it needs.

---

What You Can Do

1. Switch to X11 session (instead of Wayland) in your login manager (SDDM) and see if the problem persists.

• Wayland + NVIDIA is still less stable than X11 on many systems.

1. Update your BIOS (if available) and make sure your kernel, NVIDIA driver, and firmware are all up to date.

2. Try kernel parameters (add to your bootloader):

• usbcore.autosuspend=-1 (disables USB autosuspend)

• nvidia-drm.modeset=1 (should already be default, but check)

1. If you must use Wayland:

• Try the open-source nvidia-open kernel modules (which you are already using), but stability is still not guaranteed.

1. If you use sleep/suspend a lot and need reliability:

• Use X11 for now, or avoid suspend until NVIDIA/Wayland support matures further.

---

Summary Table

Symptom	Log Evidence	Root Cause
Freeze after resume	xhci_hcd, nvidia-drm, kwin_wayland errors	NVIDIA+Wayland+kernel bug
Taskbar/system tray QML errors	plasmashell QML TypeError logs	Graphics stack not recovered
USB device resets	xhci_hcd, USB device reset logs	USB controller resume bug

---

If you want a more stable experience with suspend/resume, use X11 for now.

If you want to troubleshoot further, let me know if you want specific steps for kernel parameter changes or more log deep-dives!

[cscs]

You might have a look at this;

https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks#Preserve_video_memory_after_suspend

[Red_AM]

These are set correctly:
PreserveVideoMemoryAllocations: 1
TemporaryFilePath: "/var/tmp"

and nvidia-suspend.service, nvidia-hibernate.service, and nvidia-resume.service are all enabled.

[cscs]

I wonder about these bits too;

• The chosen file system containing the file needs to support unnamed temporary files (e.g. ext4 or XFS) and have sufficient capacity for storing the video memory allocations (i.e. at least 5 percent more than the sum of the memory capacities of all NVIDIA GPUs). Use the command nvidia-smi --query-gpu=memory.total --format=csv,noheader,nounits to list the memory capacities of all GPUs in the system.

What filesystem is /var/tmp and do we have enough memory?

[Red_AM]

❯ nvidia-smi --query-gpu=memory.total --format=csv,noheader,nounits
8192

/var/tmp is located in my main drive for cachyos which is using a btrfs file system.

[cscs]

Ok .. I’m no expert in BTRFS .. but from my digging it appears that while it supports unnamed temporary files it is advisable to disable CoW (Copy on Write) for the directory they would be written into.

So I might suggest apply the following;

sudo chattr +C /var/tmp

References:

Btrfs - ArchWiki

[Solved] Cannot wakeup from suspend after adding RAM to 32G / Kernel &...

[Red_AM]

Done, will keep you up to date on whether it worked. Thank you for your help.

[Red_AM]

whole desktop froze but this time it wasn’t from wake, not sure what triggered it

https://paste.cachyos.org/p/6bbe3d7.log

[cscs]

Hm.
Are we sure the property was applied?

Note: From Btrfs documentation: File attributes: “When set on a directory, all newly created files will inherit this attribute. Due to implementation limitations, this flag can be set/unset only on empty files.”

Tip: In accordance with the note above, you can use the following trick to disable copy-on-write on existing files in a directory:

$ mv /path/to/dir /path/to/dir_old
$ mkdir /path/to/dir
$ chattr +C /path/to/dir
$ cp -a --reflink=never /path/to/dir_old/. /path/to/dir
$ rm -rf /path/to/dir_old

Make sure that the data are not used during this process.

Was the directory empty when chattr was applied? Because if not it may have failed.

To get ahead I might also mention in that linked thread above the user states also adding some backing swap space and enabling hibernation along with the resume hook and postulates the resume hook was the ‘fix’. I’m not sure about the correlation there, but thats what was posted anyways..

I set up hibernation in my system - added the resume hook to the kernel and pointed to my swap partition in my kernel parameters. Hibernation works as expected. But what is surprising is suspend to RAM works now as well! It seems to me that the resume hook was what was needed all along.

PS.

If this is a new system and we dont mind redoing the install .. we might also test the theory about btrfs being the issue and … just install using a different fs like XFS.
This may not be an optimum option. But I thought it might be worth leaving a note about it as it may be interesting. If only for science.

[Red_AM]

switched kernels using sudo pacman -S linux-cachyos-nvidia and haven’t had a problem since