Bug 449163 - Plasma panel visually freezes after some time under Wayland
Summary: Plasma panel visually freezes after some time under Wayland
Status: CLOSED UPSTREAM
Alias: None
Product: plasmashell
Classification: Plasma
Component: Panel (show other bugs)
Version: 5.27.10
Platform: openSUSE Linux
: VHI major
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: regression, wayland
: 448844 448878 449021 449202 449323 449825 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-01-25 17:19 UTC by sombragris
Modified: 2024-02-03 10:16 UTC (History)
56 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Example of Replicating the Freezing Taskbar Defect (3.32 MB, application/octet-stream)
2023-04-23 14:52 UTC, mark
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sombragris 2022-01-25 17:19:29 UTC
SUMMARY
Plasma panel becomes unresponsive after an indefinite amount of time under Wayland.

After some time in operation, the panel no longer updates its information. Neither the task manager nor the system clock updates (and one keeps thinking "ok, it's 16:30" when really it's 18:00).

The degree of unresponsiveness varies. The system clock gets unresponsive at all times, as well as the task manager. The system tray sometimes manages to stay responsive. Same for the pager. Other times,  however, everything is unresponsive.

The only way to get out of this, save for rebooting, is to issue the command:
```
plasmashell --replace
```
Then the panel restarts and is responsive once again until the next time it becomes unresponsive.

STEPS TO REPRODUCE
1. Boot into Plasma Desktop under Wayland
2. Wait some time
3. Notice the unresponsiveness of the panel.

OBSERVED RESULT
The panel is unresponsive in varying degrees, from just the task manager and system clock to everything.

EXPECTED RESULT
The panel should be responsive and work as intended.

SOFTWARE/OS VERSIONS
Operating System: Slackware 15.0
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.3
Kernel Version: 5.15.16 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 15,5 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620


ADDITIONAL INFORMATION
Comment 1 aTosser 2022-01-25 17:23:34 UTC
I suffer the same problem on gentoo.

Operating System: Gentoo Linux 2.8
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.16.0-gentoo (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor
Memory: 31.4 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1660 Ti/PCIe/SSE2
Comment 2 aTosser 2022-01-25 17:26:38 UTC
dupe of 429211?
Comment 3 sombragris 2022-01-25 18:07:38 UTC
Don't think this is a dupe of bug 429211. That bug specifically states that functionality is restored after some interaction.
In this case no amount of interaction restores functionality other than replacing the shell with plasmashell --replace.
Comment 4 Nate Graham 2022-01-27 00:16:38 UTC
I can reproduce with current git master on Wayland. What I see is that it visually freezes, but actually remains interactive. Clicking on things works, but the panel doesn't visually update as it usually does. We are getting lots of reports of this.

Since you're on 5.23.5, it doesn't seem to be a regression somewhere in Plasma itself. Possible an issue with a recently-backported Qt patch, or Mesa, or the kernel.

FWIW I also have an Intel UHD Graphics 620 GPU.
Comment 5 Nate Graham 2022-01-27 00:16:44 UTC
*** Bug 449202 has been marked as a duplicate of this bug. ***
Comment 6 David Haymond 2022-01-27 00:49:06 UTC
Same issue on Fedora 35.

Operating System: Fedora Linux 35
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.89.0
Qt Version: 5.15.2
Kernel Version: 5.15.16-200.fc35.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i7-1195G7 @ 2.90GHz
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics
Comment 7 sombragris 2022-01-27 03:30:49 UTC
(In reply to Nate Graham from comment #4)
> What I see is that it
> visually freezes, but actually remains interactive. Clicking on things
> works, but the panel doesn't visually update as it usually does. We are
> getting lots of reports of this.

Not exactly this. Sometimes interactivity remains; on taskbar, for example, sometimes you can't switch to another window by clicking its placeholder in taskbar. On the clock, it doesn't even show a tooltip on hover. So, not much interactivitty.
Comment 8 sombragris 2022-01-27 03:35:15 UTC
(In reply to Nate Graham from comment #4)

> Since you're on 5.23.5, it doesn't seem to be a regression somewhere in
> Plasma itself. Possible an issue with a recently-backported Qt patch, or
> Mesa, or the kernel.

Found this on the Slackware changelog:

> l/qt5-5.15.3_20211130_014c375b-x86_64-2.txz: Rebuilt.
>       Applied upstream patch:
>       [PATCH] Move the wayland socket polling to a separate event thread.

So this might be a culprit, perhaps.
Comment 9 Samuel 2022-01-27 17:02:56 UTC
Seems like this is similar issue I had - Bug 448844. Excluding the crashing behavior when doing `plasmashell --replace`, everything sounds similar.
Comment 10 Nate Graham 2022-01-27 17:05:53 UTC
*** Bug 448844 has been marked as a duplicate of this bug. ***
Comment 11 Andreas Sturmlechner 2022-01-27 21:32:52 UTC
(In reply to atosser from comment #1)
> I suffer the same problem on gentoo.

You can downgrade to stable qtwayland in Gentoo.
Comment 12 aTosser 2022-01-27 21:38:54 UTC
(In reply to Andreas Sturmlechner from comment #11)
> (In reply to atosser from comment #1)
> > I suffer the same problem on gentoo.
> 
> You can downgrade to stable qtwayland in Gentoo.

That is not an option as without this patch wayland is completely useless on Nvidia hardware.
Comment 13 Prajna Sariputra 2022-01-28 05:20:58 UTC
This issue has occurred several times for me after upgrading the qt5-wayland package in Arch Linux from 5.15.2+kde+r41-1 to 5.15.2+kde+r44-1. A few days ago I downgraded qt5-wayland back to r41 and it hasn't happened since, until I updated it to r45 (currently the latest available version), then the issue came back.

Looking at the updated Arch PKGBUILD[1] I see that the difference between r41 and r44 is three commits, all of which come from this MR: https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/24

[1]: https://github.com/archlinux/svntogit-packages/commit/844d032fa6a64d8c6ecb1e785105d2807d1b1193#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a

System information just in case:

Operating System: Arch Linux
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.16.2-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 530
Comment 14 Nate Graham 2022-01-28 21:06:10 UTC
It's not exactly the same as Bug 429211, but the root cause will be the same.

*** This bug has been marked as a duplicate of bug 429211 ***
Comment 15 sombragris 2022-01-29 01:11:45 UTC
(In reply to Nate Graham from comment #14)
> It's not exactly the same as Bug 429211, but the root cause will be the same.
> 
> *** This bug has been marked as a duplicate of bug 429211 ***

Let's hope so. Thanks Nate!
Comment 16 Fabian Vogt 2022-02-03 17:08:44 UTC
(In reply to Nate Graham from comment #14)
> It's not exactly the same as Bug 429211, but the root cause will be the same.

This is about a regression caused by https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/24, but bug 429211 is about X11, so definitely unrelated. Reopening.
Comment 17 Fabian Vogt 2022-02-03 17:11:24 UTC
A possible fix is under review upstream: https://codereview.qt-project.org/c/qt/qtwayland/+/393273
Comment 18 Nate Graham 2022-02-03 17:20:51 UTC
*** Bug 449323 has been marked as a duplicate of this bug. ***
Comment 19 Nate Graham 2022-02-03 17:21:03 UTC
*** Bug 449202 has been marked as a duplicate of this bug. ***
Comment 20 Nate Graham 2022-02-03 17:21:22 UTC
*** Bug 449021 has been marked as a duplicate of this bug. ***
Comment 21 Nate Graham 2022-02-03 17:21:36 UTC
*** Bug 448878 has been marked as a duplicate of this bug. ***
Comment 22 Nate Graham 2022-02-03 17:21:53 UTC
*** Bug 448844 has been marked as a duplicate of this bug. ***
Comment 23 torokati44 2022-02-06 21:48:05 UTC
I commented under #429211 because I thought I was affected by that, but I that was since turned into X11-specific, and I'm on Wayland.

This is happening on basically an hourly basis. Seeing the wrong (sometimes by a lot) time in the corner is really inconvenient sometimes.
Also, the fact that restarting plasmashell to fix this, sometimes also kills Firefox and/or Discord, which is a whole another issue, I imagine.
Comment 24 Lyubomir 2022-02-06 23:39:38 UTC
(In reply to torokati44 from comment #23)
> I commented under #429211 because I thought I was affected by that, but I
> that was since turned into X11-specific, and I'm on Wayland.
> 
> This is happening on basically an hourly basis. Seeing the wrong (sometimes
> by a lot) time in the corner is really inconvenient sometimes.
> Also, the fact that restarting plasmashell to fix this, sometimes also kills
> Firefox and/or Discord, which is a whole another issue, I imagine.

It may be happening on an hourly basis (haven't noticed), but there is no need for Plasma to be active for an hour for the issue to happen. That is, i once restarted Plasma because of this issue and it was only a matter of few minutes until it freezed again. That said, i did not restart Plasma immediately, so it might have been an hour since it froze.
Comment 25 madcatx 2022-02-07 10:16:55 UTC
Can any of you try to apply this patch to Qt 5.15 and check if the issue persists? It seems to fix the problem for me but I can just be lucky.

FYI, the patch is the same thing mentioned in #17 backported to apply to kde/5.15 branch of qtwayland

diff --git a/src/client/qwaylandwindow.cpp b/src/client/qwaylandwindow.cpp
index 4c5711a0..76a448e6 100644
--- a/src/client/qwaylandwindow.cpp
+++ b/src/client/qwaylandwindow.cpp
@@ -648,27 +648,20 @@ void QWaylandWindow::handleFrameCallback()
     mFrameCallbackElapsedTimer.invalidate();
 
     // The rest can wait until we can run it on the correct thread
-    if (!mWaitingForUpdateDelivery) {
-        auto doHandleExpose = [this]() {
-            bool wasExposed = isExposed();
-            mFrameCallbackTimedOut = false;
-            if (!wasExposed && isExposed()) // Did setting mFrameCallbackTimedOut make the window exposed?
-                sendExposeEvent(QRect(QPoint(), geometry().size()));
-            if (wasExposed && hasPendingUpdateRequest())
-                deliverUpdateRequest();
-
-            mWaitingForUpdateDelivery = false;
-        };
-
-        // Queued connection, to make sure we don't call handleUpdate() from inside waitForFrameSync()
-        // in the single-threaded case.
-        mWaitingForUpdateDelivery = true;
-        QMetaObject::invokeMethod(this, doHandleExpose, Qt::QueuedConnection);
-    }
+    QMetaObject::invokeMethod(this, &QWaylandWindow::doHandleFrameCallback, Qt::QueuedConnection);
 
     mFrameSyncWait.notify_all();
 }
 
+void QWaylandWindow::doHandleFrameCallback() {
+    bool wasExposed = isExposed();
+    mFrameCallbackTimedOut = false;
+    if (!wasExposed && isExposed()) // Did setting mFrameCallbackTimedOut make the window exposed?
+       sendExposeEvent(QRect(QPoint(), geometry().size()));
+    if (wasExposed && hasPendingUpdateRequest())
+       deliverUpdateRequest();
+}
+
 bool QWaylandWindow::waitForFrameSync(int timeout)
 {
     QMutexLocker locker(&mFrameSyncMutex);
diff --git a/src/client/qwaylandwindow_p.h b/src/client/qwaylandwindow_p.h
index d45980a8..f31d3fcb 100644
--- a/src/client/qwaylandwindow_p.h
+++ b/src/client/qwaylandwindow_p.h
@@ -228,7 +228,6 @@ protected:
     WId mWindowId;
     bool mWaitingForFrameCallback = false;
     bool mFrameCallbackTimedOut = false; // Whether the frame callback has timed out
-    bool mWaitingForUpdateDelivery = false;
     int mFrameCallbackCheckIntervalTimerId = -1;
     QElapsedTimer mFrameCallbackElapsedTimer;
     struct ::wl_callback *mFrameCallback = nullptr;
@@ -285,6 +284,7 @@ private:
 
     static const wl_callback_listener callbackListener;
     void handleFrameCallback();
+    void doHandleFrameCallback();
 
     static QWaylandWindow *mMouseGrab;
 
-- 
2.35.1
Comment 26 Bug Janitor Service 2022-02-07 10:22:17 UTC
A possibly relevant merge request was started @ https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/34
Comment 27 Fabian Vogt 2022-02-07 10:24:33 UTC
(In reply to madcatx from comment #25)
> Can any of you try to apply this patch to Qt 5.15 and check if the issue
> persists? It seems to fix the problem for me but I can just be lucky.

There are two more fixes pending upstream: https://codereview.qt-project.org/c/qt/qtwayland/+/393828/1
and https://codereview.qt-project.org/c/qt/qtwayland/+/393826/1.

I made a (draft) MR with all three on https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/34. Would be good to know whether anyone still has the issue with those fixes applied.
Comment 28 madcatx 2022-02-07 10:32:12 UTC
Brilliant, MR applied! I'll report back if I run into anything.
Comment 29 Tommaso Fonda 2022-02-07 11:28:47 UTC
(In reply to Fabian Vogt from comment #27)
> Would be good to
> know whether anyone still has the issue with those fixes applied.

I've applied your patches and rebuilt the component. I'll let you know if I still run into any problem. Thank you for your work.
Comment 30 aTosser 2022-02-08 08:58:41 UTC
> I made a (draft) MR with all three on
> https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/34. Would be good to
> know whether anyone still has the issue with those fixes applied.

I have been running this patch since you posted it. It does seem to correct the issues with the panel. I don't notice any obvious regressions. However, needle meet haystack.
Comment 31 Matej Mrenica 2022-02-08 09:00:30 UTC
I've also been running the MR and so far so good.
Comment 32 Patrick Silva 2022-02-08 14:36:49 UTC
Same problem with Plasma 5.34 on Arch Linux.

Operating System: Arch Linux
KDE Plasma Version: 5.24.0
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Graphics Platform: Wayland
Comment 33 Vlad Zahorodnii 2022-02-09 06:58:07 UTC
Since https://codereview.qt-project.org/c/qt/qtwayland/+/393273 was backported to KDE's qt patch collection, this bug report can be closed now.
Comment 34 Antonio Rojas 2022-02-09 09:19:55 UTC
*** Bug 449825 has been marked as a duplicate of this bug. ***
Comment 35 David Chmelik 2022-02-11 06:16:22 UTC
It's NOT originally a Wayland bug but has been happening since KDE Plasma 4 started, and into Plasma 5.  The panel used to stay frozen for as long as a half-hour or hour until I maybe killed plasmashell or KDE.  Sometimes it worked to restart/fork plasmashell in a screen session in a xterm.  Now it might still sort of work except your minimized system tray programs won't reappear there, only on taskbar (and some in background, have to kill them) which will no longer be in the order you moved programs to.
          This bug for the last 10 or 12+ years is why I initially switched back to KDE3.5 for a few major versions of Slackware until KDE3.5  stopped working, then tried to switch to TDE KDE3.5 fork and simpler (less power-hungry, even though I don't use many effects) desktop environments and still will try to switch.  I still love KDE and will report bugs, but I haven't seen the panel freeze bug ever stop.  Sometimes at the same time, some/most/all other things stop responding too.
        People suggested turn off indexing, which I did, which didn't improve situation.  If I leave KDE on for days the panel is probably bound to stop responding.  One thing that did seem to exacerbate it is if I start 10 or 15+ GUI programs immediately on starting KDE, which sometimes permanently slowed it down.  If I start one program then another after a minute or two or after disc activity died down (though my OS is on SSD, /home is on HDD) and continue in that fashion, usually it doesn't slow down.  The thing is, even if I start 15+ programs at once, it might just be 10% CPU resources of my 32 threads is even being used, so the parallel processing might need to improve (unless that situation is only a HDD access problem.)
Comment 36 torokati44 2022-02-11 17:48:02 UTC
Updating to qt5-qtwayland-5.15.2-18.fc35 fixed these freezes for me. Thanks a bunch! ^^
Comment 37 Méven Car 2022-05-15 07:06:11 UTC
(In reply to David Chmelik from comment #35)
> It's NOT originally a Wayland bug but has been happening since KDE Plasma 4
> started, and into Plasma 5.  The panel used to stay frozen for as long as a
> half-hour or hour until I maybe killed plasmashell or KDE.  Sometimes it
> worked to restart/fork plasmashell in a screen session in a xterm.  Now it
> might still sort of work except your minimized system tray programs won't
> reappear there, only on taskbar (and some in background, have to kill them)
> which will no longer be in the order you moved programs to.
>           This bug for the last 10 or 12+ years is why I initially switched
> back to KDE3.5 for a few major versions of Slackware until KDE3.5  stopped
> working, then tried to switch to TDE KDE3.5 fork and simpler (less
> power-hungry, even though I don't use many effects) desktop environments and
> still will try to switch.  I still love KDE and will report bugs, but I
> haven't seen the panel freeze bug ever stop.  Sometimes at the same time,
> some/most/all other things stop responding too.
>         People suggested turn off indexing, which I did, which didn't
> improve situation.  If I leave KDE on for days the panel is probably bound
> to stop responding.  

There are a lot of other possible causes for a process to freeze like Plasma.

For this bug, we addressed one of the causes we could precisely identify.

> One thing that did seem to exacerbate it is if I start
> 10 or 15+ GUI programs immediately on starting KDE, which sometimes
> permanently slowed it down.  If I start one program then another after a
> minute or two or after disc activity died down (though my OS is on SSD,
> /home is on HDD) and continue in that fashion, usually it doesn't slow down.
> The thing is, even if I start 15+ programs at once, it might just be 10% CPU
> resources of my 32 threads is even being used, so the parallel processing
> might need to improve (unless that situation is only a HDD access problem.)

You are describing a Xorg bug and contention due its protocol design. (If you run a recent distro did you compare with wayland?)
Or at least a different issue. 
We need bugs reports to be focused on a single issue or they become unmanageable.
Feel free to open new bugs or find those that correspond more closely to your symptoms.
Maybe one of the duplicates was wrongfully marked to duplicate this one, then comment on the duplicated one.
Comment 38 Raul José Chaves 2022-07-04 04:43:40 UTC
I'm having the exactly same symptoms right now, I'm not sure the issue was resolved.

Operating System: Manjaro Linux
KDE Plasma Version: 5.25.2
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.5
Kernel Version: 5.15.52-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1660 SUPER/PCIe/SSE2
Comment 39 Ivan Sosnov 2022-11-16 16:54:34 UTC
Still having this issue today, with the following package versions:

plasma-desktop 5.26.3-1
qt5-base 5.15.7+kde+r174-1
frameworkintegration 5.99.0-1
plasma-wayland-session 5.26.3-1
plasma-wayland-protocols 1.9.0-1
wayland-protocols 1.28-1
nvidia-dkms 520.56.06-2
linux60-tkg-bore 6.0.8-272
Comment 40 Niko N. 2022-12-10 15:27:10 UTC
I'm still experiencing this issue as well. I can confirm the reports of the task bar visually freezing but remaining responsive to mouse inputs to a certain degree.

Operating System: KDE neon 5.26
KDE Plasma Version: 5.26.4
KDE Frameworks Version: 5.100.0
Qt Version: 5.15.7
Kernel Version: 5.15.0-56-generic (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-6700K CPU @ 4.60GHz
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1080/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Comment 41 Alex Barrero 2023-01-06 20:09:16 UTC
I'm also affected by this issue. On a fresh startup, sometimes the system clock freezes until some movement with the mouse is made. Elements remain interactive.

Operating System: KDE neon 5.26
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.7
Kernel Version: 5.15.0-57-generic (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 580 Series
Manufacturer: ASUS
Comment 42 Nate Graham 2023-01-06 20:12:34 UTC
That's a different issue caused by a recent regression in the AMD drivers: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7624.

In general please file a new bug report instead of re-opening an old one that's marked as already fixed. Thanks!
Comment 43 kde 2023-04-01 11:27:47 UTC
I am also experiencing this bug, let me know if I can provide more info:

Operating System: Fedora Linux 37
KDE Plasma Version: 5.27.3
KDE Frameworks Version: 5.104.0
Qt Version: 5.15.8
Kernel Version: 6.2.8-200.fc37.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3080/PCIe/SSE2

I also found this https://www.reddit.com/r/kde/comments/10i1s81/plasma_526_panel_freezing_with_wayland_nvidia/, so I don't know if the culprit is KDE, Nvidia, Wayland, Firefox, or a combination of all these
Comment 44 kde.5qfxr 2023-04-14 01:35:36 UTC
Alright, so i think i've found what caused this problem in my case. I'm on Nobara Linux 37 (Plasma) with an Nvidia GPU. 
I was having the KDE panel always freeze after a certain amount of time as well as the steam client/games becoming unresponsive and crashing also. The solution posted here seems to have fixed it for me https://github.com/ValveSoftware/steam-for-linux/issues/9035#issuecomment-1401432123
Comment 45 kde.5qfxr 2023-04-14 13:34:26 UTC
(In reply to kde.5qfxr from comment #44)
> Alright, so i think i've found what caused this problem in my case. I'm on
> Nobara Linux 37 (Plasma) with an Nvidia GPU. 
> I was having the KDE panel always freeze after a certain amount of time as
> well as the steam client/games becoming unresponsive and crashing also. The
> solution posted here seems to have fixed it for me
> https://github.com/ValveSoftware/steam-for-linux/issues/9035#issuecomment-
> 1401432123

an update: steam client still crashes but the KDE panel at least seems to have stopped crashing
Comment 46 madcatx 2023-04-14 13:49:17 UTC
(In reply to kde.5qfxr from comment #44)
> Alright, so i think i've found what caused this problem in my case. I'm on
> Nobara Linux 37 (Plasma) with an Nvidia GPU. 
> I was having the KDE panel always freeze after a certain amount of time as
> well as the steam client/games becoming unresponsive and crashing also. The
> solution posted here seems to have fixed it for me
> https://github.com/ValveSoftware/steam-for-linux/issues/9035#issuecomment-
> 1401432123

This bug report is about plasma panels visually freezing, not crashing. Issue related to an out-of-memory condition would cause the whole plasma-desktop process to quit so the panel would disappear altogether. I don't believe that the Steam issue is relevant here.
Comment 47 Moritz Moeller-Herrmann 2023-04-19 07:37:44 UTC
Still occurring on siduction (Debian unstable) with Nvidia Wayland. Panel freezes optically (clock does not change), but interaction remains possible.
Comment 48 mark 2023-04-23 14:52:56 UTC
Created attachment 158356 [details]
Example of Replicating the Freezing Taskbar Defect
Comment 49 mark 2023-04-23 14:55:06 UTC
Comment on attachment 158356 [details]
Example of Replicating the Freezing Taskbar Defect

I can get this to happen almost 100%.

Mouse over the icon for Firefox, immediately click, and don't move the mouse while it opens. The taskbar will be frozen in the Firefox loading animation.
Comment 50 mark 2023-04-23 18:30:32 UTC
Sorry, here is my version information:

SOFTWARE/OS VERSIONS
Operating System: Gentoo Linux 2.13
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.102.0
Qt Version: 5.15.8
Kernel Version: 6.1.19-gentoo--ZDY1ig-- (64-bit)
Graphics Platform: Wayland
Processors: 128 × AMD Ryzen Threadripper 3990X 64-Core Processor
Memory: 125.7 GiB of RAM
Graphics Processor: AMD Radeon RX 6950 XT
Manufacturer: ASUS
Comment 51 Nate Graham 2023-04-24 17:06:54 UTC
As mentioned earlier, please submit new bug reports rather than re-opening or adding info to an already-closed one. The symptoms may look similar or the same, but the root cause may be different. Thanks.
Comment 52 mark 2023-04-24 17:39:04 UTC
Sorry about that! I misunderstood the bug report.
Comment 53 Anna 2023-06-08 04:40:30 UTC
While this issue has gotten more infrequent over the last monthish with regular bleeding edge updates, it still persists. Weirdly today it was acting strange before that, I would try to open dolphin by clicking a small icon next to my kde menu but it would minimize my running game of Final Fantasy XIV instead (hypothetically, and/or ACT as well) and while the panel is responsive, it has weird behavior sometimes and doesn't work as expected. Posting my system stats in case it helps, seems like this is happening to nvidia users overall (wayland problems in nvidia? whoda thunk?)

Operating System: Gentoo Linux 2.13
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.106.0
Qt Version: 5.15.9
Kernel Version: 6.3.6-gentoo (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor
Memory: 30.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2
Manufacturer: ASRock
Product Name: X670E Steel Legend
Comment 54 Antti Savolainen 2023-06-26 16:21:22 UTC
I'll add my participation to the pile. I'm having the same issue

Operating System: Arch Linux
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.107.0
Qt Version: 5.15.10
Kernel Version: 6.3.8-arch1-1-bcachefs-git
Graphics Platform: Wayland
Processors: Intel Core i5-6600K
Graphics Card: GeForce GTX 1060 6GB
Comment 55 homie 2023-07-14 16:50:44 UTC
Also have this issue. Would like to note that going into Edit Mode and dragging the panel around (towards the side of the screen so it's forced to re-layout to vertical) fixes the issue for me.

Operating System: Arch Linux 
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.4.3-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2060/PCIe/SSE2
Comment 56 Antti Savolainen 2023-07-15 07:27:50 UTC
No need to drag it around. Just change the height by one pixel and it starts working again
Comment 57 kodatarule 2023-07-25 19:05:37 UTC
Not exactly sure if it is connected, but sometimes when using floating panel and have maximized window it stops maximizing with the window complete ignores it.

Operating System: EndeavourOS 
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.4.5-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor
Memory: 31,2 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3090/PCIe/SSE2
Comment 58 Simon Gleissner 2023-07-27 13:58:45 UTC
I have the same issue with the frozen clock & panel.

Operating System: openSUSE Tumbleweed 20230724
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.4.4-1-default (64-bit)
Graphics Platform: Wayland
Processors: 16 × 11th Gen Intel® Core™ i9-11950H @ 2.60GHz
Memory: 31.1 GiB of RAM
Graphics Processor: NVIDIA RTX A3000 Laptop GPU/PCIe/SSE2
Manufacturer: LENOVO
Product Name: 20YQ000TGE
System Version: ThinkPad P15 Gen 2i
Comment 59 jilen 2023-08-16 06:58:42 UTC
This bug very likely related to task manager. 
When I switched to `latte-task` (comes from latte-dock). Panel won't get frozen any more.
Comment 60 6py0qu6f6 2023-08-25 13:57:00 UTC
I also have this bug on arch & nvidia.
Comment 61 6py0qu6f6 2023-08-25 13:57:55 UTC
I also have this bug on arch nvidia.
Comment 62 Kevin López Brante 2023-08-28 21:35:58 UTC
I have this same bug in Arch Linux. 
inxi output:
System:
  Host: ruxtower Kernel: 6.5.0-1-cachyos arch: x86_64 bits: 64
    Desktop: KDE Plasma v: 5.27.7 Distro: Arch Linux
Memory:
  System RAM: total: 32 GiB available: 31.16 GiB used: 8.86 GiB (28.4%)
  Array-1: capacity: 128 GiB slots: 4 modules: 4 EC: None
  Device-1: Controller0-ChannelA-DIMM0 type: DDR4 size: 8 GiB
    speed: 3200 MT/s
  Device-2: Controller0-ChannelA-DIMM1 type: DDR4 size: 8 GiB
    speed: 3200 MT/s
  Device-3: Controller1-ChannelA-DIMM0 type: DDR4 size: 8 GiB
    speed: 3200 MT/s
  Device-4: Controller1-ChannelA-DIMM1 type: DDR4 size: 8 GiB
    speed: 3200 MT/s
Graphics:
  Device-1: NVIDIA GA106 [GeForce RTX 3060 Lite Hash Rate] driver: nvidia
    v: 535.104.05
  Device-2: Lenovo 500 RGB Camera driver: uvcvideo type: USB
  Display: server: X.Org v: 23.2 with: Xwayland v: 23.2.0 driver: X:
    loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa
    gpu: nvidia,nvidia-nvswitch resolution: 1: 1920x1080~60Hz
    2: 1920x1080~60Hz
  API: OpenGL v: 4.6.0 NVIDIA 535.104.05 renderer: NVIDIA GeForce RTX
    3060/PCIe/SSE2
Comment 63 Robert 2023-09-05 09:20:57 UTC
I have also been experiencing this bug, and it seemed to be happening on its own after random time intervals but I managed to get it to happen consistently and immediately. It's possible this comment should be a new/separate bug with the same behavior, but I think it's very possible people are not actually doing NOTHING until the taskbar becomes unresponsive. I personally did not observe the taskbar freezing if I truly did nothing with the computer.

Providing additional steps to reproduce that may lead to a fix:

STEPS TO REPRODUCE
1. Boot into Plasma Desktop under Wayland.
2. Right click task manager -> Configure icons-only task manager -> Icons-only task manager settings -> Behavior.
3. Set "Group" to "by program name".
4. Enable "Mouse wheel cycles through tasks", apply if needed.
5. Open multiple windows of any one application that supports multiple windows (I tried this separately with Firefox, Dolphin, and Konsole).
6. Position the cursor over the icon in the icons-only task manager for that application.
7. Use the mouse wheel to cycle between open windows of that application.
8. Notice the unresponsiveness of the panel.

Using the mouse wheel to switch between open windows consistently and immediately (or within a few seconds) renders the panel unresponsive. Sometimes, changing the grouping or mouse wheel scroll settings in task manager settings and applying will also cause this behavior.

For me at least, this bug is tied directly to "mouse wheel: cycles through tasks" for programs "grouped: by program name" in the icons-only task manager. Using Latte-dock instead may be a temporary workaround for some.

Can anyone confirm if they were experiencing this bug when doing absolutely nothing at all, just leaving the computer idle for x amount of time? Are you also able to reproduce with the steps provided / is it applicable to you?

I would look into fixing this myself, but I'm not experienced with OS, Kernel, or Desktop development so it would take me a WHILE to find the source code, branch and parse through the source code, learn the appropriate language(s), set up a testing environment, fix it on my end, and push/request merge the fix. Hopefully this helps someone on the KDE team close this bug.

PS: please go easy on me, this is my first comment here so I might not know this specific group's standards.

RELATED NOTES
* Steps 2-4 may be default settings, which could also explain why the issue is so pervasive. 
* Scrolling just on the taskbar to cycle through all windows does not produce the result, it is only when hovering over a grouped icon which limits the cycle to a single application.
* Clicking to cycle also does NOT produce the result, only scrolling.
* I saw somewhere that it could be tied to virtual desktops or other widgets, but none were the case for me.
* Seems to be an issue across distros, KDE versions, AMD and Intel CPUs, and AMD and NVidia graphics cards.
* Linking a related Reddit thread with more people experiencing this issue. It does not have this insight, but has a good summary from KDE ruling things out: https://www.reddit.com/r/kde/comments/snhb2c/kde_panel_plasma_frozen_what_to_try/
* The task manager will generally still open a program if you click on the icon, even though visually it is unresponsive.

Since it's not listed here, I'm generally running the following command to reset the taskbar, which may have different behavior from `plasmashell --replace` but there seem to be variations of a similar thing:

```
systemctl --user restart plasma-plasmashell.service
```

ABOUT THIS SYSTEM
Operating System: openSUSE Tumbleweed 20230902
KDE Plasma Version: 5.27.7
KDE Frameworks Version: 5.109.0
Qt Version: 5.15.10
Kernel Version: 6.4.11-1-default (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600X 6-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2
Comment 64 Robert Svensson 2023-09-07 09:39:22 UTC
(In reply to Robert from comment #63)
> I have also been experiencing this bug, and it seemed to be happening on its
> own after random time intervals but I managed to get it to happen
> consistently and immediately. It's possible this comment should be a
> new/separate bug with the same behavior, but I think it's very possible
> people are not actually doing NOTHING until the taskbar becomes
> unresponsive. I personally did not observe the taskbar freezing if I truly
> did nothing with the computer.
> 
> Providing additional steps to reproduce that may lead to a fix:
> 
> STEPS TO REPRODUCE
> 1. Boot into Plasma Desktop under Wayland.
> 2. Right click task manager -> Configure icons-only task manager ->
> Icons-only task manager settings -> Behavior.
> 3. Set "Group" to "by program name".
> 4. Enable "Mouse wheel cycles through tasks", apply if needed.
> 5. Open multiple windows of any one application that supports multiple
> windows (I tried this separately with Firefox, Dolphin, and Konsole).
> 6. Position the cursor over the icon in the icons-only task manager for that
> application.
> 7. Use the mouse wheel to cycle between open windows of that application.
> 8. Notice the unresponsiveness of the panel.
> 
> Using the mouse wheel to switch between open windows consistently and
> immediately (or within a few seconds) renders the panel unresponsive.
> Sometimes, changing the grouping or mouse wheel scroll settings in task
> manager settings and applying will also cause this behavior.
> 
> For me at least, this bug is tied directly to "mouse wheel: cycles through
> tasks" for programs "grouped: by program name" in the icons-only task
> manager. Using Latte-dock instead may be a temporary workaround for some.
> 
> Can anyone confirm if they were experiencing this bug when doing absolutely
> nothing at all, just leaving the computer idle for x amount of time? Are you
> also able to reproduce with the steps provided / is it applicable to you?
> 
> I would look into fixing this myself, but I'm not experienced with OS,
> Kernel, or Desktop development so it would take me a WHILE to find the
> source code, branch and parse through the source code, learn the appropriate
> language(s), set up a testing environment, fix it on my end, and
> push/request merge the fix. Hopefully this helps someone on the KDE team
> close this bug.
> 
> PS: please go easy on me, this is my first comment here so I might not know
> this specific group's standards.
> 
> RELATED NOTES
> * Steps 2-4 may be default settings, which could also explain why the issue
> is so pervasive. 
> * Scrolling just on the taskbar to cycle through all windows does not
> produce the result, it is only when hovering over a grouped icon which
> limits the cycle to a single application.
> * Clicking to cycle also does NOT produce the result, only scrolling.
> * I saw somewhere that it could be tied to virtual desktops or other
> widgets, but none were the case for me.
> * Seems to be an issue across distros, KDE versions, AMD and Intel CPUs, and
> AMD and NVidia graphics cards.
> * Linking a related Reddit thread with more people experiencing this issue.
> It does not have this insight, but has a good summary from KDE ruling things
> out:
> https://www.reddit.com/r/kde/comments/snhb2c/
> kde_panel_plasma_frozen_what_to_try/
> * The task manager will generally still open a program if you click on the
> icon, even though visually it is unresponsive.
> 
> Since it's not listed here, I'm generally running the following command to
> reset the taskbar, which may have different behavior from `plasmashell
> --replace` but there seem to be variations of a similar thing:
> 
> ```
> systemctl --user restart plasma-plasmashell.service
> ```
> 
> ABOUT THIS SYSTEM
> Operating System: openSUSE Tumbleweed 20230902
> KDE Plasma Version: 5.27.7
> KDE Frameworks Version: 5.109.0
> Qt Version: 5.15.10
> Kernel Version: 6.4.11-1-default (64-bit)
> Graphics Platform: Wayland
> Processors: 12 × AMD Ryzen 5 3600X 6-Core Processor
> Memory: 15.5 GiB of RAM
> Graphics Processor: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2

I can also confirm this behavior. In my case however it DOES happen with ungrouped windows. In fact when testing it just now I didn't have any grouped windows in the task manager at all. Just hovering above any given window's icon in the task manager and scrolling will immediately freeze the panel for me like how it's described in the initial report. My task manager settings are however the same as yours otherwise.

Whether or not this is a separate issue I'm not sure, but at least it's a consistent repro of the effects of the original reported bug. I will say though that I never use the scroll wheel to switch between windows normally, and still experience the issue frequently. So it seems to be triggered by something else too, perhaps some other window switching/focus related action.
Comment 65 Nate Graham 2023-09-07 13:13:24 UTC
If you have an NVIDIA GPU, you're experiencing Bug 469016; please post comments there, not here.
Comment 66 Robert 2023-09-08 06:26:29 UTC
(In reply to Nate Graham from comment #65)
> If you have an NVIDIA GPU, you're experiencing Bug 469016; please post
> comments there, not here.

I didn't see any indication that this bug is exclusive to AMD, and bug 469016 is not exclusive to NVIDIA either, but I'll follow up there.

Bug 469016 was reported as happening under "heavy load" and unhiding a hidden task bar, which is not applicable to me. That said, recent discussion tying it to window previews and pipewire is relevant. Going to Configure Icons-only Task Manager -> Appearance -> General -> and disabling "Show small window previews when hovering over tasks" prevents the issues for me.

(In reply to Robert Svensson from comment #64)
> I can also confirm this behavior. In my case however it DOES happen with ungrouped windows. In fact when testing it just now I didn't have any grouped windows in the task manager at all. Just hovering above any given window's icon in the task manager and scrolling will immediately freeze the panel for me like how it's described in the initial report. My task manager settings are however the same as yours otherwise.
>
> Whether or not this is a separate issue I'm not sure, but at least it's a consistent repro of the effects of the original reported bug. I will say though that I never use the scroll wheel to switch between windows normally, and still experience the issue frequently. So it seems to be triggered by something else too, perhaps some other window switching/focus related action.

I didn't experience it without grouped windows, but scrolling even with the scroll setting disabled still causes it unless "Show small window previews when hovering over tasks" is disabled. Disabling window previews prevents the issue for me, although this workflow is not ideal. Maybe the root cause is the same for both, maybe not, but hopefully this at least points some people in the right direction.
Comment 67 Raul José Chaves 2023-09-09 15:39:01 UTC
> I didn't see any indication that this bug is exclusive to AMD, and bug
> 469016 is not exclusive to NVIDIA either, but I'll follow up there.

For me, it actually seems related to NVIDIA, I was having this issue with my 1660s all the time, after I switched to my 6700XT without changing any other component the issue was gone, with the same setup, on manjaro, using the classic task manager ungrouped.
Comment 68 Benedek Szabó 2023-10-01 20:50:08 UTC
I have the same problem
Distro: Arch
Kernel: 6.5.5-arch1-1
Desktop: Plasma 5.27.8 Wayland
GPU: Nvidia RTX 2060 with 535.113.01-2 driver
Comment 69 Jakub Kusal 2023-11-09 21:06:24 UTC
Happens to me aswell 100% of the times when using Wayland session.
OS: Debian GNU/Linux trixie/sid x86_64 
Host: 81Q4 Lenovo Legion Y540-17IRH 
Shell: zsh 5.9 
DE: Plasma 5.27.9 Wayland
WM: kwin 
CPU: Intel i7-9750H (12) @ 2.601GHz 
GPU: NVIDIA GeForce GTX 1660 Ti Mobile 
Memory: 7835MiB / 15898MiB
Comment 70 Simon Gleissner 2023-11-10 10:04:28 UTC
(In reply to Simon Gleissner from comment #58)
> I have the same issue with the frozen clock & panel.
> 
> Operating System: openSUSE Tumbleweed 20230724
> KDE Plasma Version: 5.27.6
> KDE Frameworks Version: 5.108.0
> Qt Version: 5.15.10
> Kernel Version: 6.4.4-1-default (64-bit)
> Graphics Platform: Wayland
> Processors: 16 × 11th Gen Intel® Core™ i9-11950H @ 2.60GHz
> Memory: 31.1 GiB of RAM
> Graphics Processor: NVIDIA RTX A3000 Laptop GPU/PCIe/SSE2
> Manufacturer: LENOVO
> Product Name: 20YQ000TGE
> System Version: ThinkPad P15 Gen 2i

I have an update, which might be interesting for others. As a workaround, I have started using the opensource nouveau driver instead of the closed source nvidia driver. This was not an option before, as nouveau had stability issues on this GPU with my Thunderbolt docking station with 2 external monitors, wayland and a KVM switch. This seems to became much better, even if the instabilities with the KVM switch are not yet gone. However, both problems I had with the closed source drivers (hanging Plasma panel/clock and flickering graphic errors with xwayland) seem to be gone now.
Comment 71 Teclado 2023-12-11 21:49:38 UTC
Still happening in Plasma 5.27.10.
Apparently related to the amount of use of the panel.

Plasma: 5.27.10
KDE Frameworks: 5.112.0
QT: 5.15.11
Kernel: 6.6.3-1-default (64 bits)
GPU: NVIDIA GeForce RTX 3060/PCIe/SSE2
Comment 72 feich 2023-12-18 17:35:44 UTC
Wayland Plasma 5.27.10 is still ongoing both openSUSE tumbleweed and Fedora 39 Spin KDE.

Duplication step.
Task-Manager mouse hover show thumbnail option is active.
Open Firefox and watch any video. 
Meanwhile, move cursor on to Firefox icon and wait showing thumbnail.
symptoms do not start after doing this, click on the clock or volume panel and return to the icon.
If you repeat this cycle at certain intervals, Task manager will stop responding.

It seems like live preview of the video is causing this.

I'm not sure if this may have an effect, but I'll leave it here as additional information. (While this is happening firefox nvidia-vaapi video decoding is on.)

Plasma: 5.27.10
KDE Frameworks: 5.112.0
QT: 5.15.11
Kernel: 6.6.6-1-default (64 bits)
GPU: NVIDIA GeForce RTX 2080
Comment 73 saif1988 2024-01-26 14:33:25 UTC
Came here to say: happens to me too.

OpenSUSE Tumbleweed
Plasma: 5.27.10
KDE Frameworks: 5.114.0
QT: 5.15.12
Kernel: 6.7.1-1-default (64 bits)
GPU: NVIDIA GeForce RTX 3070
Graphics Platform: Wayland
Comment 74 Asha 2024-02-03 10:16:58 UTC
Adding my name to the list; I have the same problem.

I've resorted to running a script to restart Plasma every 5 minutes - which is less than ideal.

Arch Linux x86_64
Kernel: 6.7.3-arch1-1 (64-bit)
KDE Plasma: 5.27.10
KDE Frameworks: 5.114.0
QT: 5.15.12
Graphics Platform: Wayland
GPU: NVIDIA GeForce GTX 1080 Ti