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

dupe of 429211?

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.

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.

*** Bug 449202 has been marked as a duplicate of this bug. ***

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

(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.

(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.

Seems like this is similar issue I had - Bug 448844. Excluding the crashing behavior when doing `plasmashell --replace`, everything sounds similar.

*** Bug 448844 has been marked as a duplicate of this bug. ***

(In reply to atosser from comment #1)
> I suffer the same problem on gentoo.

You can downgrade to stable qtwayland in Gentoo.

(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.

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

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 ***

(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!

(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.

A possible fix is under review upstream: https://codereview.qt-project.org/c/qt/qtwayland/+/393273

*** Bug 449323 has been marked as a duplicate of this bug. ***

*** Bug 449202 has been marked as a duplicate of this bug. ***

*** Bug 449021 has been marked as a duplicate of this bug. ***

*** Bug 448878 has been marked as a duplicate of this bug. ***

*** Bug 448844 has been marked as a duplicate of this bug. ***

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.

(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.

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

A possibly relevant merge request was started @ https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/34

(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.

Brilliant, MR applied! I'll report back if I run into anything.

(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.

> 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.

I've also been running the MR and so far so good.

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

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.

*** Bug 449825 has been marked as a duplicate of this bug. ***

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.)

Updating to qt5-qtwayland-5.15.2-18.fc35 fixed these freezes for me. Thanks a bunch! ^^

(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.

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

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

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.

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

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!