Bug 449163 - Plasma panel visually freezes after some time under Wayland
Summary: Plasma panel visually freezes after some time under Wayland
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Panel (show other bugs)
Version: 5.23.5
Platform: Slackware 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: 2023-01-06 20:12 UTC (History)
35 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

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!