https://bugs.kde.org/show_bug.cgi?id=525008
A.C <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from A.C <[email protected]> --- I can reproduce this on a hybrid Intel + NVIDIA desktop and caught the main thread during a hang: it waits in a futex inside the NVIDIA EGL driver, called from EglGbmLayerSurface::importBuffer. System: - Fedora 44, kernel 7.2.11-200.fc44.x86_64 - KWin 6.7.5 (kwin-6.7.5-1.fc44), Plasma Wayland session - NVIDIA RTX 4090, proprietary driver 615.78.08 (render GPU, 0000:01:00.0) - Intel iGPU, Mesa 26.2.5 (0000:00:02.0) - Two monitors: DP-3 on the RTX 4090, DP-6 on the Intel iGPU, so every frame for DP-6 goes through the multi-GPU import path Symptom: While the Unity Editor (an X11 app on Xwayland, rendering with OpenGL; -force-vulkan gives the same result) loads the NVIDIA GPU, the whole desktop freezes for about 1-3 seconds every few minutes: the cursor stops and video playback stops. After each freeze the journal logs: kwin_wayland[9393]: The main thread was hanging temporarily! There are no Xid/NVRM errors in the kernel log. How I captured it: A root script pings KWin over D-Bus (org.kde.KWin /KWin Introspect) every 0.5 s. When no reply comes within 0.75 s, it samples /proc/<kwin>/task/<kwin>/syscall every 0.1 s, then runs eu-stack -1 and gdb. Main thread syscall samples. The futex wait was still going on 0.75 s after the hang started, then the thread went back to its normal ppoll idle: 11:15:08.344 futex 202 0x55dd4fbe6ca8 0x189 0x0 0x0 0x0 0xffffffff ... 11:15:08.447 futex 202 0x55dd4fbe6ca8 0x189 ... 11:15:08.550 futex 202 0x55dd4fbe6ca8 0x189 ... 11:15:08.653 futex 202 0x55dd4fbe6ca8 0x189 ... 11:15:08.756 ppoll 271 ... (event loop idle again) Main thread stack during the futex wait (eu-stack -1 -p <kwin>): #0 0x00007f64ca47a034 #1 0x00007f64ca47d4ee #2 0x00007f64ca47eef6 #3 0x00007f64ca496d01 #4 0x00007f64ca3664d3 #5 0x00007f64ca468e7e #6 0x00007f64ca41a02b #7 0x00007f64ca41a89f #8 0x00007f64ca08b63a #9 KWin::EglGbmLayerSurface::importBuffer(KWin::EglGbmLayerSurface::Surface*, KWin::EglSwapchainSlot*, KWin::FileDescriptor&&, KWin::OutputFrame*, KWin::Region const&) const #10 KWin::EglGbmLayerSurface::endRendering(KWin::Region const&, KWin::OutputFrame*) #11 KWin::Compositor::composite(KWin::RenderLoop*)::{lambda()#1}::operator()() const #12 KWin::Compositor::composite(KWin::RenderLoop*) #13 doActivate<false> #14 KWin::RenderLoop::frameRequested(KWin::RenderLoop*) ... #22 QCoreApplication::exec() #23 main Frames #0-#8 have no symbols. They are in the address range of libnvidia-eglcore.so.615.78.08: gdb resolves other threads' frames to that library at 0x7f64ca37b4b0, 0x7f64ca6f699a and 0x7f64ca86be41. gdb only attached after the hang had ended, so its all-thread dump shows the main thread idle again and adds nothing here. So, as in the original report, the main thread blocks in importBuffer when another client keeps the NVIDIA GPU busy. In my case it also happens without opening or closing windows, and with the import going to a second GPU. My guess is that the import synchronizes with the NVIDIA GPU's queue on the main thread, so the whole compositor waits behind the other client's GPU work. Workaround: after moving the second monitor from the Intel iGPU to the RTX 4090 (so no output needs the multi-GPU import), this hang has not come back. -- You are receiving this mail because: You are watching all bug changes.
