| Summary: | Memory leaks and instabilities with different GPUs driving multi-monitor setups when a screen wakes / is added | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Lech <misc> |
| Component: | performance | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | major | CC: | 2014cais01, accounts, antonio.tigri, barra, boris.v.petrov, brauliobo, bumblebeepllxd124, charlyghislain, clash-raisin-liver, colin, crjohnsten, cydiaimpactor2003, eclipse, eclipseo, elman, erik, evorster, fabiodanielreis, fdevrijer, filipembedded, haventhefrog, hsantanna, jarrard, jp.mnsss, kde.2ip0k, kde, kde, kde, kdedev, krorkle, leledumbo_cool, linus+kde, LucasGGamerM, maciej.witkowski256, me, mike, mira.jary, mscastanho, nate, neodzc2012, ojosdeserbio, orzalek, paravoid, paul.may9115, pikalp32, piotr.brzozowski, postix, qethanmoore+kde, radimir.cacic09, righn, robbe.profiles, roman, serhiihatcan, sh200105, shastao, sla763, sowieso, steadily_dismount201, surinmike, therealchubbypanda, tom, vigorous_freeload690, xaver.hugl, zabotinskis30 |
| Priority: | HI | Keywords: | multiscreen, wayland-only |
| Version First Reported In: | 6.2.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/2eac8c7783ef6963662b1015c211e8a8d81414d9 | Version Fixed/Implemented In: | |
| Sentry Crash Report: | |||
| Attachments: |
journalctl output
signature.asc attachment-8514-0.html attachment-2827128-0.html attachment-2251139-0.html attachment-2578341-0.html attachment-670598-0.html perf report from kwin_wayland while memory leak perf report from kwin_wayland 6.3.90 nvidia-open 575.51.02 signature.asc |
||
|
Description
Lech
2024-11-19 16:40:43 UTC
I can confirm this. KWin ate more than 12GB of my memory oO Operating System: Arch Linux KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.11.9-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × Intel® Core™ i7-10850H CPU @ 2.70GHz Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics, external monitor is connected through Nvidia card though GP2: NVIDIA GeForce GTX 1650 Ti with Max-Q Design Manufacturer: LENOVO Product Name: 20TKCTO1WW System Version: ThinkPad X1 Extreme Gen 3 11月 21 19:26:17 workpad kernel: Out of memory: Killed process 1077 (kwin_wayland) total-vm:16333436kB, anon-rss:182896kB, file-rss:12580488kB, shmem-rss:451928kB, UID:1000 pgtables:27612kB oom_score_adj:200 11月 21 19:26:17 workpad kernel: WebExtensions[3114]: segfault at 0 ip 00007467e66005a1 sp 00007ffd65ca87a0 error 6 in libxul.so[55ff5a1,7467e2afe000+5ec4000] likely on CPU 8 (core 2, socket 0) 11月 21 19:26:17 workpad kernel: Code: 8b 04 25 28 00 00 00 48 3b 44 24 28 75 2d 48 83 c4 30 5b 41 5e 5d c3 48 8b 3b ff 15 11 b9 86 02 48 8b 0d 1a b6 86 02 48 89 01 <c7> 04 25 00 00 00 00 b2 00 00 00 ff 15 0e b6 86 02 e8 f9 09 3c 02 11月 21 19:26:18 workpad systemd-journald[429]: Under memory pressure, flushing caches. 11月 21 19:26:03 workpad kwin_wayland[1077]: kwin_wayland_drm: Pageflip timed out! This is a kernel bug Same thing happening on my system. Operating System: Arch Linux KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.12.1-2-cachyos (64-bit) Graphics Platform: Wayland Processors: Ryzen 7 5800H Memory: 16GB Graphics Processor: RTX 3060, external monitor uses that Manufacturer: HP Product Name: Omen 15.6" Is it possible that kwin developers to look into this? Using KDE now with multiple monitors is like moving into lovely Windows 95 times, with 2 Plasma restarts per day... There's a high chance this is fixed by https://invent.kde.org/plasma/kwin/-/merge_requests/6845, so I'm closing this. If it still happens in 6.2.5, just reopen this bug report! (In reply to Zamundaaa from comment #4) > There's a high chance this is fixed by > https://invent.kde.org/plasma/kwin/-/merge_requests/6845, so I'm closing > this. If it still happens in 6.2.5, just reopen this bug report! Thank you. Will check when 6.2.5 reaches Fedora. I really hope that solves it and 6.2.5 gets released soon. I noticed that KWin returns it's memory if the second screen gets replugged after getting unplugged once (physically pulling the HDMI cable). Not a nice workaround, but better than having to log in again. (In reply to sowieso from comment #6) > I really hope that solves it and 6.2.5 gets released soon. > I noticed that KWin returns it's memory if the second screen gets replugged > after getting unplugged once (physically pulling the HDMI cable). > Not a nice workaround, but better than having to log in again. I've noticed something like that too, although not tested extensively. However, I notice some lagging after these operations. Not sure it is related, so I am waiting for solving this bug before (hopefully not) reporting more. This issue is still present on 6.2.5. kwin_wayland reached a 10GB usage as per btop at one point. I can confirm, that the issue is still present in KDE 6.2.5 on Fedora 40, making KDE barely usable on my multi-monitor NVidia Optimus laptop setup. Perhaps I'll find a way to downgrade it to 6.2.3 or it will work better on X... I can also confirm that this is still present in kwin_wayland 6.2.5. In my case, the memory consumption is rising at around 3 GB per second. Unplugging the HDMI cable and plugging it back in indeed causes the memory to be released (thanks, sowieso@dukun.de). Operating System: Fedora Linux 41 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.12.7-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 20 × 12th Gen Intel® Core™ i9-12900H Memory: 31.0 GiB of RAM Graphics Processor: Mesa Intel® Iris® Xe Graphics Manufacturer: Micro-Star International Co., Ltd. Product Name: Stealth GS66 12UH System Version: REV:1.0 (In reply to Roman Teterin from comment #10) > I can also confirm that this is still present in kwin_wayland 6.2.5. > In my case, the memory consumption is rising at around 3 GB per second. > Unplugging the HDMI cable and plugging it back in indeed causes the memory > to be released (thanks, sowieso@dukun.de). > > Operating System: Fedora Linux 41 > KDE Plasma Version: 6.2.5 > KDE Frameworks Version: 6.9.0 > Qt Version: 6.8.1 > Kernel Version: 6.12.7-200.fc41.x86_64 (64-bit) > Graphics Platform: Wayland > Processors: 20 × 12th Gen Intel® Core™ i9-12900H > Memory: 31.0 GiB of RAM > Graphics Processor: Mesa Intel® Iris® Xe Graphics > Manufacturer: Micro-Star International Co., Ltd. > Product Name: Stealth GS66 12UH > System Version: REV:1.0 Sorry, I meant 3 GB per hour, of course. Created attachment 177296 [details]
journalctl output
Above is the log generated with sudo journalctl --boot 0 --grep=nvidia >> nvidia-memory-leak-log.txt && sudo journalctl --boot 0 --identifier=kwin_wayland >> nvidia-memory-leak-log.txt && sudo journalctl --boot 0 --identifier=kwin_wayland_wrapper >> nvidia-memory-leak-log.txt as given in https://bugs.kde.org/show_bug.cgi?id=496898. The relevant part starts on 12 Jan 10:35, as it is when I woke up my laptop. Could you update us if anyone is trying to fix this issue? This is important, because due to the very serious nature of this instability and the level of unusability it causes, we may have to start looking for an alternative to KDE if no fix is planned in the near future... I have tried to reproduce the issue, but it doesn't happen here, with Intel + NVidia. Memory usage stayed very constant at about 320MiB while using the external monitor and letting glxgears spin on the external monitor for two hours to ensure whatever small leak could happen would actually be visible. And I assume you tested it after waking up from sleep? The fact that it happens for several people would suggest a difference in configuration (maybe it has to be AMD+Nvidia?) (In reply to Zamundaaa from comment #15) > I have tried to reproduce the issue, but it doesn't happen here, with Intel > + NVidia. Memory usage stayed very constant at about 320MiB while using the > external monitor and letting glxgears spin on the external monitor for two > hours to ensure whatever small leak could happen would actually be visible. I have Intel + Nvidia notebook Could everyone that has the issue please comment the NVidia driver version they're using? On this laptop I have driver version 565.77-12, on kernel 6.12.10 (In reply to Zamundaaa from comment #15) > I have tried to reproduce the issue, but it doesn't happen here, with Intel > + NVidia. Memory usage stayed very constant at about 320MiB while using the > external monitor and letting glxgears spin on the external monitor for two > hours to ensure whatever small leak could happen would actually be visible. I have an Dell WD15 dock, the monitor is connected to it using HDMI and then dock's Type-C cable is connected to the laptop. As I use this dock for work also, so I quite often would switch out my work laptop with my own laptop on the dock. So everytime make the switch - disconnect my own laptop, connect the work laptop and after work disconnect the work laptop and connect my own, wake it up from sleep, the memory leak happens. But a simple kwin_wayland --replace fixes it. I'm on NVIDIA 565.77-263 I wonder if something like how the HDMI output port is routed has an impact. Is it wired directly to the dGPU or through the iGPU. (In reply to Zamundaaa from comment #18) > Could everyone that has the issue please comment the NVidia driver version > they're using? > > On this laptop I have driver version 565.77-12, on kernel 6.12.10 I have 565.77 (not sure how to get subnumber) on kernel 6.12.8-100.fc40.x86_64 okay, so it's probably not the driver version. (In reply to righn from comment #19) > I have an Dell WD15 dock, the monitor is connected to it using HDMI and then > dock's Type-C cable is connected to the laptop. As I use this dock for work > also, so I quite often would switch out my work laptop with my own laptop on > the dock. So everytime make the switch - disconnect my own laptop, connect > the work laptop and after work disconnect the work laptop and connect my > own, wake it up from sleep, the memory leak happens. But a simple > kwin_wayland --replace fixes it. > > I'm on NVIDIA 565.77-263 How much memory is leaked when you unplug the screen / how much memory usage does KWin gain on re-plug? (In reply to Zamundaaa from comment #22) > okay, so it's probably not the driver version. > > (In reply to righn from comment #19) > > I have an Dell WD15 dock, the monitor is connected to it using HDMI and then > > dock's Type-C cable is connected to the laptop. As I use this dock for work > > also, so I quite often would switch out my work laptop with my own laptop on > > the dock. So everytime make the switch - disconnect my own laptop, connect > > the work laptop and after work disconnect the work laptop and connect my > > own, wake it up from sleep, the memory leak happens. But a simple > > kwin_wayland --replace fixes it. > > > > I'm on NVIDIA 565.77-263 > How much memory is leaked when you unplug the screen / how much memory usage > does KWin gain on re-plug? It happens gradually. For example, right now, I unplugged the screen - kwin_wayland used about 290MB, replugged it, it started at about 320MB and starts increasing gradually. While I was writing this comment, it already increased by 100MB, so it's at 440MB already. Here it depends on how I am using the machine. If I leave it be, kwin_wayland may gain a few GB in a few hours. If I use it, for example for web browsing, it may gain the same amount in one hour. (In reply to Zamundaaa from comment #18) > Could everyone that has the issue please comment the NVidia driver version > they're using? > > On this laptop I have driver version 565.77-12, on kernel 6.12.10 On my laptop I have version 565.77-3, kernel 6.12.9-200. Disconnected and re-connected the external monitor 15 minutes ago, just to make sure that the issue is still present. Memory usage dropped from 440 to around 380 MB and then started to rise gradually. Now it's at 1 GB and is still rising. Okay, maybe the import mode could be different. Please put > QT_LOGGING_RULES="kwin_wayland_*.debug=true" into /etc/environment, reboot, connect the external monitor and check the output of > journalctl --user-unit plasma-kwin_wayland --boot 0 | grep import for which multi-gpu copy mode your system is using, and > wayland-info | grep NVIDIA and > wayland-info | grep INTEL (or AMD) for which GPU is the primary one on your system journalctl --user-unit plasma-kwin_wayland --boot 0 | grep import Journal file /var/log/journal/49739eb258bf4717b5bb4420280b45ab/system@000629a3af917a7a-efdf6713f41a1159.journal~ is truncated, ignoring file. Jan 24 19:27:45 lwpcomp4 kwin_wayland[3128]: kwin_wayland_drm: chose egl import with format AB30 and modifier 0 Jan 24 19:27:45 lwpcomp4 kwin_wayland[3128]: kwin_wayland_drm: chose egl import with format AB30 and modifier 0 Jan 24 19:27:54 lwpcomp4 kwin_wayland[3128]: kwin_wayland_drm: chose cpu import with format AR24 and modifier 0 Jan 24 19:27:55 lwpcomp4 kwin_wayland[3128]: kwin_wayland_drm: chose cpu import with format AR24 and modifier 0 wayland-info | grep NVIDIA gives nothing wayland-info | grep AMD 0x32335247 = 'GR32'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x32335247 = 'GR32'; 0x0200000010467b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x32335247 = 'GR32'; 0x0200000010437b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_64B,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=64B,PIPE_XOR_BITS=2 0x32335247 = 'GR32'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x32335247 = 'GR32'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x48344258 = 'XB4H'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x48344258 = 'XB4H'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x48344258 = 'XB4H'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x35314241 = 'AB15'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x35314241 = 'AB15'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x35314241 = 'AB15'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x48344241 = 'AB4H'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x48344241 = 'AB4H'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x48344241 = 'AB4H'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x35315241 = 'AR15'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x35315241 = 'AR15'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x35315241 = 'AR15'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x38344258 = 'XB48'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x38344258 = 'XB48'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x38344258 = 'XB48'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x36314752 = 'RG16'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x36314752 = 'RG16'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x36314752 = 'RG16'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x32314241 = 'AB12'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x32314241 = 'AB12'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x32314241 = 'AB12'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x38385247 = 'GR88'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x38385247 = 'GR88'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x38385247 = 'GR88'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x20203852 = 'R8 '; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x20203852 = 'R8 '; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x20203852 = 'R8 '; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x3231564e = 'NV12'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x3231564e = 'NV12'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x20363152 = 'R16 '; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x20363152 = 'R16 '; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x20363152 = 'R16 '; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x38344241 = 'AB48'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x38344241 = 'AB48'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x38344241 = 'AB48'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x32315241 = 'AR12'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x32315241 = 'AR12'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x32315241 = 'AR12'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x34324241 = 'AB24'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x34324241 = 'AB24'; 0x0200000010467b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x34324241 = 'AB24'; 0x0200000010437b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_64B,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=64B,PIPE_XOR_BITS=2 0x34324241 = 'AB24'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x34324241 = 'AB24'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x34324258 = 'XB24'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x34324258 = 'XB24'; 0x0200000010467b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x34324258 = 'XB24'; 0x0200000010437b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_64B,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=64B,PIPE_XOR_BITS=2 0x34324258 = 'XB24'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x34324258 = 'XB24'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x34325241 = 'AR24'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x34325241 = 'AR24'; 0x0200000010467b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x34325241 = 'AR24'; 0x0200000010437b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_64B,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=64B,PIPE_XOR_BITS=2 0x34325241 = 'AR24'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x34325241 = 'AR24'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x34325258 = 'XR24'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x34325258 = 'XR24'; 0x0200000010467b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x34325258 = 'XR24'; 0x0200000010437b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_64B,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=64B,PIPE_XOR_BITS=2 0x34325258 = 'XR24'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x34325258 = 'XR24'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x30334241 = 'AB30'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x30334241 = 'AB30'; 0x0200000010467b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x30334241 = 'AB30'; 0x0200000010437b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_64B,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=64B,PIPE_XOR_BITS=2 0x30334241 = 'AB30'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x30334241 = 'AB30'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x30334258 = 'XB30'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x30334258 = 'XB30'; 0x0200000010467b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x30334258 = 'XB30'; 0x0200000010437b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_64B,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=64B,PIPE_XOR_BITS=2 0x30334258 = 'XB30'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x30334258 = 'XB30'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x30335241 = 'AR30'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x30335241 = 'AR30'; 0x0200000010467b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x30335241 = 'AR30'; 0x0200000010437b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_64B,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=64B,PIPE_XOR_BITS=2 0x30335241 = 'AR30'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x30335241 = 'AR30'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D 0x30335258 = 'XR30'; 0x020000001046bb04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x30335258 = 'XR30'; 0x0200000010467b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,PIPE_XOR_BITS=2 0x30335258 = 'XR30'; 0x0200000010437b04 = AMD_GFX11,GFX9_64K_R_X,DCC,DCC_RETILE,DCC_INDEPENDENT_64B,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=64B,PIPE_XOR_BITS=2 0x30335258 = 'XR30'; 0x0200000010401b04 = AMD_GFX11,GFX9_64K_R_X,PIPE_XOR_BITS=2 0x30335258 = 'XR30'; 0x0200000000000a04 = AMD_GFX11,GFX9_64K_D (In reply to Zamundaaa from comment #26) > Okay, maybe the import mode could be different. Please put > > QT_LOGGING_RULES="kwin_wayland_*.debug=true" > into /etc/environment, reboot, connect the external monitor and check the > output of > > journalctl --user-unit plasma-kwin_wayland --boot 0 | grep import > for which multi-gpu copy mode your system is using, and > > wayland-info | grep NVIDIA > and > > wayland-info | grep INTEL > (or AMD) for which GPU is the primary one on your system Added the env var, rebooted, reconnected the monitor to "initiate" the memory leak and these are the results: journalctl --user-unit plasma-kwin_wayland --boot 0 | grep import saus. 24 20:32:24 archomen kwin_wayland[984]: kwin_wayland_drm: chose egl import with format AB30 and modifier 0 saus. 24 20:32:24 archomen kwin_wayland[984]: kwin_wayland_drm: chose cpu import with format AR24 and modifier 0 saus. 24 20:32:59 archomen kwin_wayland[984]: kwin_wayland_drm: chose egl import with format AB30 and modifier 0 saus. 24 20:33:11 archomen kwin_wayland[984]: kwin_wayland_drm: chose cpu import with format AR24 and modifier 0 wayland-info | grep NVIDIA empty wayland-info | grep AMD 0x35315241 = 'AR15'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x35315241 = 'AR15'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x35315241 = 'AR15'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x35315241 = 'AR15'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x35315241 = 'AR15'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x35315241 = 'AR15'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x3231564e = 'NV12'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x3231564e = 'NV12'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x3231564e = 'NV12'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x3231564e = 'NV12'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x38344241 = 'AB48'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x38344241 = 'AB48'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x38344241 = 'AB48'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x38344241 = 'AB48'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x38344241 = 'AB48'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x38344241 = 'AB48'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x32315241 = 'AR12'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x32315241 = 'AR12'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x32315241 = 'AR12'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x32315241 = 'AR12'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x32315241 = 'AR12'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x32315241 = 'AR12'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x38344258 = 'XB48'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x38344258 = 'XB48'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x38344258 = 'XB48'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x38344258 = 'XB48'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x38344258 = 'XB48'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x38344258 = 'XB48'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x32335247 = 'GR32'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x32335247 = 'GR32'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x32335247 = 'GR32'; 0x0200000440517901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_RETILE 0x32335247 = 'GR32'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x32335247 = 'GR32'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x32335247 = 'GR32'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x32335247 = 'GR32'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x20363152 = 'R16 '; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x20363152 = 'R16 '; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x20363152 = 'R16 '; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x20363152 = 'R16 '; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x20363152 = 'R16 '; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x20363152 = 'R16 '; 0x0200000000000901 = AMD_GFX9,64KB_S 0x48344241 = 'AB4H'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x48344241 = 'AB4H'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x48344241 = 'AB4H'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x48344241 = 'AB4H'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x48344241 = 'AB4H'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x48344241 = 'AB4H'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x38385247 = 'GR88'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x38385247 = 'GR88'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x38385247 = 'GR88'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x38385247 = 'GR88'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x38385247 = 'GR88'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x38385247 = 'GR88'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x32314241 = 'AB12'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x32314241 = 'AB12'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x32314241 = 'AB12'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x32314241 = 'AB12'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x32314241 = 'AB12'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x32314241 = 'AB12'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x20203852 = 'R8 '; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x20203852 = 'R8 '; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x20203852 = 'R8 '; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x20203852 = 'R8 '; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x20203852 = 'R8 '; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x20203852 = 'R8 '; 0x0200000000000901 = AMD_GFX9,64KB_S 0x36314752 = 'RG16'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x36314752 = 'RG16'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x36314752 = 'RG16'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x36314752 = 'RG16'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x36314752 = 'RG16'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x36314752 = 'RG16'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x48344258 = 'XB4H'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x48344258 = 'XB4H'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x48344258 = 'XB4H'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x48344258 = 'XB4H'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x48344258 = 'XB4H'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x48344258 = 'XB4H'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x35314241 = 'AB15'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x35314241 = 'AB15'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x35314241 = 'AB15'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x35314241 = 'AB15'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x35314241 = 'AB15'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x35314241 = 'AB15'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x34324258 = 'XB24'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x34324258 = 'XB24'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x34324258 = 'XB24'; 0x0200000440517901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_RETILE 0x34324258 = 'XB24'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x34324258 = 'XB24'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x34324258 = 'XB24'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x34324258 = 'XB24'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x34324241 = 'AB24'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x34324241 = 'AB24'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x34324241 = 'AB24'; 0x0200000440517901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_RETILE 0x34324241 = 'AB24'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x34324241 = 'AB24'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x34324241 = 'AB24'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x34324241 = 'AB24'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x34325241 = 'AR24'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x34325241 = 'AR24'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x34325241 = 'AR24'; 0x0200000440517901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_RETILE 0x34325241 = 'AR24'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x34325241 = 'AR24'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x34325241 = 'AR24'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x34325241 = 'AR24'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x34325258 = 'XR24'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x34325258 = 'XR24'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x34325258 = 'XR24'; 0x0200000440517901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_RETILE 0x34325258 = 'XR24'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x34325258 = 'XR24'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x34325258 = 'XR24'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x34325258 = 'XR24'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x30334258 = 'XB30'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x30334258 = 'XB30'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x30334258 = 'XB30'; 0x0200000440517901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_RETILE 0x30334258 = 'XB30'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x30334258 = 'XB30'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x30334258 = 'XB30'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x30334258 = 'XB30'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x30335241 = 'AR30'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x30335241 = 'AR30'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x30335241 = 'AR30'; 0x0200000440517901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_RETILE 0x30335241 = 'AR30'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x30335241 = 'AR30'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x30335241 = 'AR30'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x30335241 = 'AR30'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x30334241 = 'AB30'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x30334241 = 'AB30'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x30334241 = 'AB30'; 0x0200000440517901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_RETILE 0x30334241 = 'AB30'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x30334241 = 'AB30'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x30334241 = 'AB30'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x30334241 = 'AB30'; 0x0200000000000901 = AMD_GFX9,64KB_S 0x30335258 = 'XR30'; 0x020000044051ba01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x30335258 = 'XR30'; 0x020000044051b901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_PIPE_ALIGN 0x30335258 = 'XR30'; 0x0200000440517901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0,RB=1,PIPE=2,DCC,DCC_MAX_COMPRESSED_BLOCK=64B,DCC_INDEPENDENT_64B,DCC_CONSTANT_ENCODE,DCC_RETILE 0x30335258 = 'XR30'; 0x0200000000401a01 = AMD_GFX9,64KB_D_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x30335258 = 'XR30'; 0x0200000000401901 = AMD_GFX9,64KB_S_X,PIPE_XOR_BITS=2,BANK_XOR_BITS=0 0x30335258 = 'XR30'; 0x0200000000000a01 = AMD_GFX9,64KB_D 0x30335258 = 'XR30'; 0x0200000000000901 = AMD_GFX9,64KB_S (In reply to Zamundaaa from comment #26) > Okay, maybe the import mode could be different. Please put > > QT_LOGGING_RULES="kwin_wayland_*.debug=true" > into /etc/environment, reboot, connect the external monitor and check the > output of > > journalctl --user-unit plasma-kwin_wayland --boot 0 | grep import > for which multi-gpu copy mode your system is using, and > > wayland-info | grep NVIDIA > and > > wayland-info | grep INTEL > (or AMD) for which GPU is the primary one on your system Here is my output: > ~ % journalctl --user-unit plasma-kwin_wayland --boot 0 | grep import > Jan 26 22:52:06 workstation-roma kwin_wayland[23538]: kwin_wayland_drm: chose egl import with format AB30 and modifier 0 > Jan 26 22:52:19 workstation-roma kwin_wayland[23538]: kwin_wayland_drm: chose cpu import with format AR24 and modifier 0 > ~ % wayland-info | grep NVIDIA > ~ % wayland-info | grep INTEL > 0x38344258 = 'XB48'; 0x0100000000000001 = INTEL_X_TILED > 0x38344258 = 'XB48'; 0x0100000000000002 = INTEL_Y_TILED > 0x38344258 = 'XB48'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x38344258 = 'XB48'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x48344258 = 'XB4H'; 0x0100000000000001 = INTEL_X_TILED > 0x48344258 = 'XB4H'; 0x0100000000000002 = INTEL_Y_TILED > 0x48344258 = 'XB4H'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x48344258 = 'XB4H'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x32335247 = 'GR32'; 0x0100000000000001 = INTEL_X_TILED > 0x32335247 = 'GR32'; 0x0100000000000002 = INTEL_Y_TILED > 0x32335247 = 'GR32'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x32335247 = 'GR32'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x20203852 = 'R8 '; 0x0100000000000001 = INTEL_X_TILED > 0x20203852 = 'R8 '; 0x0100000000000002 = INTEL_Y_TILED > 0x20203852 = 'R8 '; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x20203852 = 'R8 '; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x36314752 = 'RG16'; 0x0100000000000001 = INTEL_X_TILED > 0x36314752 = 'RG16'; 0x0100000000000002 = INTEL_Y_TILED > 0x36314752 = 'RG16'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x36314752 = 'RG16'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x35315241 = 'AR15'; 0x0100000000000001 = INTEL_X_TILED > 0x35315241 = 'AR15'; 0x0100000000000002 = INTEL_Y_TILED > 0x35315241 = 'AR15'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x35315241 = 'AR15'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x48344241 = 'AB4H'; 0x0100000000000001 = INTEL_X_TILED > 0x48344241 = 'AB4H'; 0x0100000000000002 = INTEL_Y_TILED > 0x48344241 = 'AB4H'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x48344241 = 'AB4H'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x3231564e = 'NV12'; 0x0100000000000001 = INTEL_X_TILED > 0x3231564e = 'NV12'; 0x0100000000000002 = INTEL_Y_TILED > 0x38385247 = 'GR88'; 0x0100000000000001 = INTEL_X_TILED > 0x38385247 = 'GR88'; 0x0100000000000002 = INTEL_Y_TILED > 0x38385247 = 'GR88'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x38385247 = 'GR88'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x20363152 = 'R16 '; 0x0100000000000001 = INTEL_X_TILED > 0x20363152 = 'R16 '; 0x0100000000000002 = INTEL_Y_TILED > 0x20363152 = 'R16 '; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x20363152 = 'R16 '; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x38344241 = 'AB48'; 0x0100000000000001 = INTEL_X_TILED > 0x38344241 = 'AB48'; 0x0100000000000002 = INTEL_Y_TILED > 0x38344241 = 'AB48'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x38344241 = 'AB48'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x32315241 = 'AR12'; 0x0100000000000001 = INTEL_X_TILED > 0x32315241 = 'AR12'; 0x0100000000000002 = INTEL_Y_TILED > 0x32315241 = 'AR12'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x32315241 = 'AR12'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x34324241 = 'AB24'; 0x0100000000000001 = INTEL_X_TILED > 0x34324241 = 'AB24'; 0x0100000000000002 = INTEL_Y_TILED > 0x34324241 = 'AB24'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x34324241 = 'AB24'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x34324258 = 'XB24'; 0x0100000000000001 = INTEL_X_TILED > 0x34324258 = 'XB24'; 0x0100000000000002 = INTEL_Y_TILED > 0x34324258 = 'XB24'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x34324258 = 'XB24'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x34325258 = 'XR24'; 0x0100000000000001 = INTEL_X_TILED > 0x34325258 = 'XR24'; 0x0100000000000002 = INTEL_Y_TILED > 0x34325258 = 'XR24'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x34325258 = 'XR24'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x34325241 = 'AR24'; 0x0100000000000001 = INTEL_X_TILED > 0x34325241 = 'AR24'; 0x0100000000000002 = INTEL_Y_TILED > 0x34325241 = 'AR24'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x34325241 = 'AR24'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x30335241 = 'AR30'; 0x0100000000000001 = INTEL_X_TILED > 0x30335241 = 'AR30'; 0x0100000000000002 = INTEL_Y_TILED > 0x30335241 = 'AR30'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x30335241 = 'AR30'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x30334241 = 'AB30'; 0x0100000000000001 = INTEL_X_TILED > 0x30334241 = 'AB30'; 0x0100000000000002 = INTEL_Y_TILED > 0x30334241 = 'AB30'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x30334241 = 'AB30'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC > 0x30335258 = 'XR30'; 0x0100000000000001 = INTEL_X_TILED > 0x30335258 = 'XR30'; 0x0100000000000002 = INTEL_Y_TILED > 0x30335258 = 'XR30'; 0x0100000000000006 = INTEL_Y_TILED_GEN12_RC_CCS > 0x30335258 = 'XR30'; 0x0100000000000008 = INTEL_Y_TILED_GEN12_RC_CCS_CC Did out outputs provide any clue? Unfortunately not, everything looks as expected and the same as on my system. *** Bug 497056 has been marked as a duplicate of this bug. *** *** Bug 498556 has been marked as a duplicate of this bug. *** *** Bug 496898 has been marked as a duplicate of this bug. *** Trying to be helpful here: - are we all using optimus with the amd/intel GPU as the main one? - do we all have the external monitor ports connected to the same GPU? - are we all having this issue only when putting the laptop to sleep and waking it up? Coming here from https://bugs.kde.org/show_bug.cgi?id=496898 which was marked as duplicate of this issue. (In reply to Lech from comment #35) > Trying to be helpful here: > - are we all using optimus with the amd/intel GPU as the main one? AMD integrated GPU with NVidia DGPU here. > - do we all have the external monitor ports connected to the same GPU? Yes, all connected to the DGPU > - are we all having this issue only when putting the laptop to sleep and > waking it up? No for me it is triggered after plugging in an external screen while kwin_wayland is running. (In reply to Lech from comment #35) > Trying to be helpful here: > - are we all using optimus with the amd/intel GPU as the main one? > - do we all have the external monitor ports connected to the same GPU? > - are we all having this issue only when putting the laptop to sleep and > waking it up? > - are we all using optimus with the amd/intel GPU as the main one? In my case it's AMD iGPU and NVIDIA GPU. - - do we all have the external monitor ports connected to the same GPU? Yes, all of my output ports are wired to the dGPU. > - are we all having this issue only when putting the laptop to sleep and > waking it up? Not exactly. If my external monitor stays connected at the time I put my laptop to sleep and wake it up, the leak doesn't happen. The leak only happens when I disconnect the external monitor and reconnect it, doesn't matter if it was asleep or no. *** Bug 498627 has been marked as a duplicate of this bug. *** An observation. Just unplugging the HDMI cable doesn't restore the memory usage. It's plugging the HDMI cable back in, that restores the usage to normal levels. Next I'll test if after removing the cable I just let the system sit, does the memory usage (a) increases (b) decreases slowly or (c) stays the same. [SPEC] Operating System: Fedora Linux 41 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Kernel Version: 6.12.10-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × AMD Ryzen 5 3550H with Radeon Vega Mobile Gfx Memory: 17.4 GB of RAM Graphics Processor: AMD Radeon Vega 8 Graphics Manufacturer: HP Product Name: HP Pavilion Gaming Laptop 15 I'm using nvidia. (In reply to Lech from comment #35) > Trying to be helpful here: > - are we all using optimus with the amd/intel GPU as the main one? No, in my case is intel iGPU and nvidia dGPU > - do we all have the external monitor ports connected to the same GPU? Both monitors are connected to a dock and to the pc via USB-C to my laptop, and goes to dGPU (nvidia) > - are we all having this issue only when putting the laptop to sleep and > waking it up? Nop, issue can happen from a clean boot where external monitor was connected from boot (since I am using dock I am not sure what happens behind). If I can provide any more useful information I'll be glad to help. I am also experiencing this issue and same as others, unplugging and *then* re-plugging in the video cable clears up the excessive RAM usage. I have and Asus Zephyrus G15 (2021) GA503 with an AMD Ryzen 9 5900HS CPU w/iGPU and an NVIDIA 3080 dGPU. For me, I'm using a USB C to DisplayPort adapter to connect my monitor. IIRC, on this laptop, the HDMI passes through the AMD iGPU and offloads to the NVIDIA dGPU, while the USB C DisplayPort is hardwired to the dGPU. [SPEC] Operating System: Fedora Linux 41 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Kernel Version: 6.12.9-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 5900HS with Radeon Graphics Memory: 38.6 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G15 GA503QS_GA503QS (In reply to Lech from comment #35) > Trying to be helpful here: > - are we all using optimus with the amd/intel GPU as the main one? Intel iGPU and Nvidia dGPU with driver 565.77 in my case > - do we all have the external monitor ports connected to the same GPU? Using HDMI port that is connected to dGPU > - are we all having this issue only when putting the laptop to sleep and > waking it up? I experience memory leaks in two scenarios: 1. After waking up from sleep 2. After disconnecting and reconnecting external monitors Initially, I thought these scenarios were equivalent (both involving display reconnection), but comment #37 and comment #40 suggest there might be different underlying causes. I can confirm the observation from comment #24: the frequency of display repaints correlates with the rate of memory consumption, eventually using all available RAM. --- Regarding Case (2) (Display Freezing): I've also experienced the image output freezing issue mentioned in the bug description, but in my case it was specifically related to using the kzones KWin script (https://github.com/gerritdevriese/kzones). After monitor disconnection/reconnection while using this script: - ~50% of cases: Moving windows causes complete image output freeze - `kwin_wayland --replace` fails with `qt.qpa.xcb: could not connect to display` - Requires killing kwin_wayland via SSH and then SDDM appears - ~50% of cases: Only the memory leak occurs A potentially related issue was reported at https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12341#note_2657149, describing both freezing and memory leaks after sleep/wake cycles. While I am not sure to what extent the freezing behavior is related to the memory leak and everyone is discussing mostly the memory leak, I'm including this information since it was mentioned in the original bug description. *** Bug 495991 has been marked as a duplicate of this bug. *** (In reply to Lech from comment #35) > - are we all using optimus with the amd/intel GPU as the main one? In my case it's NVIDIA/Intel > - do we all have the external monitor ports connected to the same GPU? My monitor is connected to the HDMI port, I'm not sure which GPU this port is connected to, though. > - are we all having this issue only when putting the laptop to sleep and > waking it up? No, in my case it's reproducible even after a cold boot. I have a small update, not sure if it will be useful, but anyway... The built-in screen on my laptop has been having issues for the past couple of months, and a few days ago it finally died, so only the external display is working now. So, I went into the BIOS and completely disabled the built-in display. Now, only one display is shown in the system settings, and the issue is no longer reproducible. I am also facing this issue. I had it literally crash my IDE and PPT software in the middle of my tasks due to the kernel OOM mechanism kicking in. The unique part compared to all others here is that I only have an Intel iGP in my system. No dGPs. The workarounds mentioned here of unplugging and replugging the HDMI cord unfortunately doesn't work for me, and neither does temporarily switching to a VTE do anything. I have had to do unsafe shutdowns or SysRq+B in order to get out of this situation and regain usefulness of my laptop. The worst part is that I've had to run fsck manually whenever I do this since the reboot would drop me in a shell, saying I have to manually run it. Thankfully, I have had no data loss yet. Here is my laptop's specs: [SPEC] Operating System: Arch Linux KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.13.1-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × 12th Gen Intel® Core™ i7-1260P Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® Iris® Xe Graphics Manufacturer: LENOVO Product Name: 21CDCTO1WW System Version: ThinkPad X1 Yoga Gen 7 ADDITIONAL INFORMATION At it's peak, I have had it occupy upto 15.2 GB, with the only reason me being able to save my work and force exit being that I allocated 10 GB for swap, which gave me just enough time to write everything to disk. I only use one external monitor. I have the same issue with the memory leak described above.
My steps to reproduce:
1. Turn on my laptop as usual
2. For some reason the external monitor is not sowing anything at all
3. Unplug the HDMI connector from the laptop, plug it in back.
4. kwin_wayland process starts slowly leaking memory.
kwin_wayland leaks memory faster and faster after being in this state for some time. After eating up all the available RAM (31+ GiB) it gets killed by earlyoom killer.
Restarting it with kwin_wayland --replace helps me as well.
My system specs are:
Operating System: Arch Linux
KDE Plasma Version: 6.2.5
KDE Frameworks Version: 6.10.0
Qt Version: 6.8.2
Kernel Version: 6.13.2-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 20 × 12th Gen Intel® Core™ i7-12700H
Memory: 62.5 GiB of RAM
Graphics Processor: Mesa Intel® Iris® Xe Graphics
Manufacturer: Micro-Star International Co., Ltd.
Product Name: Katana GF76 12UGS
System Version: REV:1.0
$ inxi -G
Graphics:
Device-1: Intel Alder Lake-P GT2 [Iris Xe Graphics] driver: i915 v: kernel
Device-2: NVIDIA GA104 [Geforce RTX 3070 Ti Laptop GPU] driver: nvidia
v: 570.86.16
Display: unspecified server: X.Org v: 24.1.5 with: Xwayland v: 24.1.5
driver: X: loaded: modesetting,nvidia dri: iris
gpu: i915,nvidia,nvidia-nvswitch resolution: 1: 2560x1440~144Hz
2: 1920x1080~144Hz
API: EGL v: 1.5 drivers: iris,nvidia platforms: gbm,x11,surfaceless,device
API: OpenGL v: 4.6.0 compat-v: 4.6 vendor: intel mesa v: 24.3.4-arch1.1
renderer: Mesa Intel Iris Xe Graphics (ADL GT2)
API: Vulkan v: 1.4.303 drivers: N/A surfaces: xcb,xlib
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
de: kscreen-console,kscreen-doctor gpu: nvidia-smi wl: wayland-info
x11: xdpyinfo, xprop, xrandr
$ pacman -Qi kwin
Name : kwin
Version : 6.2.5-3
...
(In reply to Chan from comment #45) > I am also facing this issue. I had it literally crash my IDE and PPT > software in the middle of my tasks due to the kernel OOM mechanism kicking > in. The unique part compared to all others here is that I only have an Intel > iGP in my system. No dGPs. Until we know differently, I would assume that to be a different problem. Please make a separate bug report about that. im unsure if what im experiencing is the same issue or not, but for me kwin_waylands memory usage gets increased by a lot by repeatedly fullscreening and unfullscreening a program, with each fullscreen the memory usage gets higher and higher with my desktop just getting more and more laggy and freezy and a full restart is needed to fix it, ive seen it go up to 8 gigs of ram before. this can get really annoying as i tend to watch youtube videos in fullscreen and i unfullscreen them multiple times to check up on messages, causing the freezes to kick in fast. Operating System: EndeavourOS KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.13.2-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-3770K CPU @ 3.50GHz Memory: 23,4 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 980 I brought this up on Matrix back when the 565 Nvidia driver update dropped, and it was suggested it could be a bug in the driver itself and not kwin, not sure if that's correct. I downgraded to 560 and never had these issues again, until I tried upgrading to 570 yesterday. The issues are back :/ The behaviour I'm observing matches exactly what kde.2ip0k@aihaiti.space described: after reconnecting a display (be it manually re-plugging or waking from sleep), the memory starts leaking pretty fast until it consumes everything. The rate at which it leaks seems somewhat related to the repainting frequency. Replacing kwin works, but is somewhat disrupting, of course, as not all windows are automatically recovered. Also requires me to restart plasmashell (otherwise it gets stuck in a weird, partially functioning state). Here's my system information: Operating System: Manjaro Linux KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.12.12-2-MANJARO (64-bit) Graphics Platform: Wayland Processors: 12 × Intel® Core™ i7-9750H CPU @ 2.60GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 630 And also inxi -G: Graphics: Device-1: Intel CoffeeLake-H GT2 [UHD Graphics 630] driver: i915 v: kernel Device-2: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] driver: N/A Display: wayland server: X.Org v: 24.1.4 with: Xwayland v: 24.1.4 compositor: kwin_wayland driver: X: loaded: modesetting unloaded: nvidia dri: iris gpu: i915 resolution: 1920x1080~144Hz API: EGL v: 1.5 drivers: iris,swrast platforms: gbm,wayland,x11,surfaceless,device API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 24.3.4-arch1.1 renderer: Mesa Intel UHD Graphics 630 (CFL GT2) API: Vulkan v: 1.4.303 drivers: N/A surfaces: xcb,xlib,wayland Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console,kscreen-doctor gpu: gputop, intel_gpu_top, lsgpu, nvidia-settings, nvidia-smi wl: swaymsg,wayland-info x11: xdpyinfo, xprop, xrandr I'm not sure why the driver is showing as N/A there. I have the nvidia-open-dkms Manjaro/Arch package at version 570.86.16-2 (latest atm). I experience the same thing. For me it stops at 11GB memory usage. If I unplug the monitor nothing happens, only when I plug it back whole Plasma restarts (closing all my apps) but then the memory usage rises much faster than it did in the first place. I have realised that it depends on the amount of pixels that have been changed since the start of the session, on a stable image it doesn't rise at all and on a video playback or when swinging a window around it rises. The leak doesn't happen at all when the iGPU is turned off in the bios. System: Arch Linux Kernel: 6.13.2-arch1-1 Plasma version: 6.3.0 Frameworks version: 6.10.0 Qt version: 6.8.2 Graphics platform: Wayland CPU: Intel Core i5 13500h iGPU: Intel Iris Xe Graphics dGPU: Nvidia RTX 4050 Mobile So I bought an external monitor a few weeks ago and it's happening to me. I am on a AMD Laptop with an integrated nvidia card too. The monitor is plugged with a USB-C to DisplayPort cable, which has occasional disconnections. I am on Fedora 41 dnf info kwin Updating and loading repositories: Repositories loaded. Installed packages Name : kwin Epoch : 0 Version : 6.3.0 Release : 3.fc41 Architecture : x86_64 Installed size : 12.0 B Source : kwin-6.3.0-3.fc41.src.rpm From repository : updates Summary : KDE Window manager URL : https://userbase.kde.org/KWin License : BSD-2-Clause AND BSD-3-Clause AND CC0-1.0 AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-only AND GPL-3.0-or-later AND L : GPL-2.0-only AND LGPL-2.0-or-later AND LGPL-2.1-only AND LGPL-2.1-or-later AND LGPL-3.0-only AND (GPL-2.0-only OR GPL-3.0-o : nly) AND (LGPL-2.1-only OR LGPL-3.0-only) AND MIT Description : KDE Window manager. Vendor : Fedora Project inxi -G Graphics: Device-1: NVIDIA GA104M [GeForce RTX 3080 Mobile / Max-Q 8GB/16GB] driver: nvidia v: 565.77 Device-2: Advanced Micro Devices [AMD/ATI] Cezanne [Radeon Vega Series / Radeon Mobile Series] driver: amdgpu v: kernel Display: wayland server: X.org v: 1.21.1.15 with: Xwayland v: 24.1.5 compositor: kwin_wayland driver: gpu: amdgpu,nvidia,nvidia-nvswitch resolution: 1: 3440x1440~165Hz 2: 2560x1440~165Hz API: EGL v: 1.5 drivers: nvidia,radeonsi platforms: gbm,wayland,x11,surfaceless,device API: OpenGL v: 4.6.0 compat-v: 4.6 vendor: amd mesa v: 24.3.4 renderer: AMD Radeon Graphics (radeonsi renoir LLVM 19.1.7 DRM 3.59 6.12.13-200.fc41.x86_64) API: Vulkan v: 1.4.304 drivers: N/A surfaces: xcb,xlib,wayland Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console,kscreen-doctor gpu: nvidia-settings, nvidia-smi, radeontop wl: wayland-info x11: xdriinfo, xdpyinfo, xprop, xrandr wayland-info | grep NVIDIA returns nothing but wayland-info | grep AMD returns something so it is most likely the main. And I have this result: journalctl --user-unit plasma-kwin_wayland --boot 0 | grep import févr. 16 14:38:20 Cassini kwin_wayland[2651]: kwin_wayland_drm: chose egl import with format AB30 and modifier 0 févr. 16 14:38:20 Cassini kwin_wayland[2651]: kwin_wayland_drm: chose egl import with format AB4H and modifier 0 Hi same issue here > Trying to be helpful here: > - are we all using optimus with the amd/intel GPU as the main one? Intel integrated GPU (i9-13980HX CPU) with NVidia 4 4080 laptopDGPU. > - do we all have the external monitor ports connected to the same GPU? I think laptop screen is on iGPU. External monitor connected to dGPU by thunderbolt 4 > - are we all having this issue only when putting the laptop to sleep and > waking it up? No, It's all the time. I use a KVM to work and having to reconnect the cord (or changing KVM source and restoring to the laptop source) is a hell. I've realised that memory leaks increases considerably when playing RTSP streaming (sourveilance camera) on VLC. I dont know if happens to while playing other kind of media. My setup: bazzite-asus-nvidia-open:stable Bazzite 41 (FROM Fedora Kinoite) Linux 6.12.12-207.bazzite.fc41.x86_64 21 hours, 53 mins Spawned on Feb 22 2025 ROG Strix G614JZ_G614JZ (1.0) 13th Gen Intel(R) Core(TM) i9-13980HX (32) @ 5.60 GHz NVIDIA GeForce RTX 4080 Max-Q / Mobile [Discrete] Intel Raptor Lake-S UHD Graphics @ 1.65 GHz [Integrated] 11.70 GiB / 30.95 GiB (38%) 14.01 GiB / 114.00 GiB (12%) - btrfs [Read-only] 14.43 GiB / 115.50 GiB (12%) - btrfs 28.63 GiB / 399.96 GiB (7%) - btrfs 538.81 GiB / 1.82 TiB (29%) - btrfs 2560x1440 @ 120 Hz (as 2048x1152) in 27" [External] 50% [AC Connected] ASUSTeK ROG CHAKRAM X KDE Plasma 6.3.0 KWin (Wayland) bash 5.2.32 Ptyxis 47.6 2683 (rpm), 56 (flatpak), 27 (brew) Hey there, same issue here. I have i5-13420H iGPU and RTX 4050 Laptop dGPU. External monitor is connected via HDMI/Thunderbolt, and is operated by dGPU. Issue occurs with or without sleep/hibernation. Other sysinfo: Operating System: Arch Linux KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.5-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 12 × 13th Gen Intel® Core™ i5-13420H Memory: 15,3 GiB of RAM Graphics Processor 1: Mesa Intel® Graphics Graphics Processor 2: llvmpipe Manufacturer: LENOVO Product Name: 82XV System Version: LOQ 15IRH8 Same issue here. Laptop MSI GS75 Stealth 9SF lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630] 01:00.0 VGA compatible controller: NVIDIA Corporation TU106M [GeForce RTX 2070 Mobile] (rev a1) Issue occurs with or without sleep/hibernation. No memory leak on X11 Other sysinfo: Operating System: Kubuntu 25.04 KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.12.0-16-generic #16-Ubuntu SMP PREEMPT_DYNAMIC Graphics Platform: Wayland Processors: 12 × i7-9750H CPU @ 2.60GHz Memory: 14 GiB of RAM Graphics Processor 1: Intel Graphics Processor 2: Nvidia Manufacturer: Micro-Star International Co., Ltd. Product Name: GS75 Stealth 9SF System Version: Ubuntu 25.04 Ubuntu Plucky Puffin (development branch) I, too, am suffering from an increased memory usage from kwin to the point of OOM, with resident memory often being at the 1.5G mark. However, unlike most (all?) reporters here I do not have a multi-GPU setup, but rather just a regular single-GPU Intel TigerLake laptop. I am usually connected to an external monitor, but when I do, my settings are configured to turn the laptop screen off, so I wouldn't even call it "multi-monitor" per se. No idea if this is the same bug as others have reported here or an entirely separate one. This is with Debian trixie, KWin 6.3.0, Wayland, HiDPI external monitor (scaling factor 2). I can find my way around gdb and Valgrind, so if you have any tips on how to best debug this, I'd love to hear them! *** Bug 497041 has been marked as a duplicate of this bug. *** I'm still seeing this issue on 6.3.2 consistently. Archlinux: AMD onboard graphics + Nvidia 3070 laptop My current workaround involves unplugging and reconnecting the external monitor once in a while when my RAM maxes out. The workaround is intermittent, sometimes the whole system freezes up on disconnecting. I have tried the env var change described in https://bbs.archlinux.org/viewtopic.php?id=301440 to no avail This looks to be at least partly caused by the sleep/wake functionality from my experience. Memory usage looks to be stable until the machine has gone through a sleep cycle. On wake when logging back into the desktop memory usage from the kwin_wayland process will steadily start to increase until an OOM causes the process to fully crash or monitors are disconnected and reconnected. From what I've seen this is also happening on machines with the following hardware set up: an internal GPU (intel/AMD) a dedicated GPU (Nvidia) plasma version: 6.3.2 Nvidia driver: 570.124.04 (In reply to Daniela Henkel from comment #48) > im unsure if what im experiencing is the same issue or not, but for me > kwin_waylands memory usage gets increased by a lot by repeatedly > fullscreening and unfullscreening a program, with each fullscreen the memory > usage gets higher and higher with my desktop just getting more and more > laggy and freezy and a full restart is needed to fix it, ive seen it go up > to 8 gigs of ram before. this can get really annoying as i tend to watch > youtube videos in fullscreen and i unfullscreen them multiple times to check > up on messages, causing the freezes to kick in fast. > > Operating System: EndeavourOS > KDE Plasma Version: 6.3.0 > KDE Frameworks Version: 6.10.0 > Qt Version: 6.8.2 > Kernel Version: 6.13.2-arch1-1 (64-bit) > Graphics Platform: Wayland > Processors: 8 × Intel® Core™ i7-3770K CPU @ 3.50GHz > Memory: 23,4 GiB of RAM > Graphics Processor: NVIDIA GeForce GTX 980 Same behaviour on my machine. I did some testing with mpv and noticed: pressing f to toggle fullscreen 16 times will guarantee a small leak. Once it has started to leak, it is guaranteed to leak again each time it leaves fullscreen. The same is true of f in VLC and Haruna, and F11 in Firefox, even on the new tab page. The 16th press is where the problem begins. There is a noticeable lag spike when the memory leaks, and again when closing the responsible program. Reboot or kwin_wayland --replace to remedy, but Firefox will close during either of these. RAM usage for mpv tests looked like this: 1.7GiB to start, with video open and playing in a small window. 16 fullscreen toggles later: the first permanent increase to 1.9GiB Subsequent fullscreen/unfullscreen cycles: 2.5, 4.8, 14.3 GiB Other runs: (kwin_wayland --replace) [1.7,(16 fullscreen toggles...) 1.8, 2.4, 4.8, 14.3] GiB (and after a reboot) [1.7,(16 fullscreen toggles...) 1.9, 2.5, 4.9, 14.4] GiB And so, with ~16GB RAM my PC crashed when leaving fullscreen on my 11th YouTube video of the session, with at most 2 tabs open in Firefox at any given time: one video, and one other tab to open new videos from. I toggled fullscreen during this session only by clicking the button at the bottom right of the video. Independent processes do not affect each other. mpv can be closed before leaking (even with alt+F4 to avoid the problematic 16th toggle), and opened again with the full 16 toggle grace. Using external video players to watch each YouTube video does escape Firefox's fullscreen limit, if otherwise less than ideal. I'd be very interested to hear if this magic number "16" (i.e. 8 times *leaving* fullscreen) is the same for anyone else. It's likely that I'll file a separate report in the morning regardless of feedback, but if anyone outside of EndeavourOS can't replicate, that would help get this to the right team. Operating System: EndeavourOS KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.5-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 2600X Six-Core Processor Memory: 15.5 GiB of RAM Graphics Processor: AMD Radeon RX 580 Series Desktop running identical dual monitors, one through a DisplayPort->HDMI adapter (In reply to Faidon Liambotis from comment #56) > I, too, am suffering from an increased memory usage from kwin to the point > of OOM, with resident memory often being at the 1.5G mark. > > However, unlike most (all?) reporters here I do not have a multi-GPU setup, > but rather just a regular single-GPU Intel TigerLake laptop. I am usually > connected to an external monitor, but when I do, my settings are configured > to turn the laptop screen off, so I wouldn't even call it "multi-monitor" > per se. > > No idea if this is the same bug as others have reported here or an entirely > separate one. > > This is with Debian trixie, KWin 6.3.0, Wayland, HiDPI external monitor > (scaling factor 2). > > I can find my way around gdb and Valgrind, so if you have any tips on how to > best debug this, I'd love to hear them! Ok, so I am not the only one with just an iGPU facing this OOM situation. Is anyone here facing this issue while running the 6.6 LTS kernel? I somehow don't face this problem when I am running the 6.6 LTS kernel. I have run the same setup (just the latest KDE 6.3.2 and Frameworks) for a week straight (no reboots) with an external monitor connected, just on the 6.6 LTS kernel, and didn't face an OOM. As such, I am now running the 6.6 LTS for the daily usage, and it's running normally with no issues. So maybe even though it's still kwin_wayland (or kwin_wayland_wrapper?) that eventually fills the memory to the point of OOM, but it's somehow an upstream kernel issue? Can someone else check this or is this a separate issue for me, and I am lucky it doesn't happen on 6.6 LTS? (In reply to comment #48) (In reply to comment #60) I have upgraded my system today and this problem seems resolved. I have closed my separate report, I hope it's resolved for you too. Operating System: EndeavourOS KDE Plasma Version: 6.3.3 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.6-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 2600X Six-Core Processor Memory: 15.5 GiB of RAM Graphics Processor: AMD Radeon RX 580 Series I'm still having this issue in 6.3.3. Memory usage slowly rises over time and resets after unplugging and replugging the external screen (USB-C dock -> HDMI) or replacing kwin_wayland. With my system it chews through 10gb of RAM in ~3 or 4 hours. Operating System: openSUSE Tumbleweed 20250313 KDE Plasma Version: 6.3.3 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.6-1-default (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 5900HS with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor 1: AMD Radeon Graphics Graphics Processor 2: llvmpipe Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G15 GA503QR_GA503QR System Version: 1.0 *** Bug 500792 has been marked as a duplicate of this bug. *** Still the same on 6.3.3 here :( (In reply to Chan from comment #62) > Is anyone here facing this issue while running the 6.6 LTS kernel? I somehow > don't face this problem when I am running the 6.6 LTS kernel. I have run the > same setup (just the latest KDE 6.3.2 and Frameworks) for a week straight > (no reboots) with an external monitor connected, just on the 6.6 LTS kernel, > and didn't face an OOM. As such, I am now running the 6.6 LTS for the daily > usage, and it's running normally with no issues. So maybe even though it's > still kwin_wayland (or kwin_wayland_wrapper?) that eventually fills the > memory to the point of OOM, but it's somehow an upstream kernel issue? Can > someone else check this or is this a separate issue for me, and I am lucky > it doesn't happen on 6.6 LTS? Indeed this is likely a kernel issue anyone reported to amdgpu and nvidia-open? I also have the same issue. I'm using Fedora 41 (KDE Spin) on an Acer Nitro 5 with a discrete NVIDIA GPU. I use it with the laptop lid closed and an external monitor plugged. This problem has been bugging me for a few weeks now, multiple times a day. I have a system with 32GB of RAM that gets completely taken by kwin_wayland after some time.
The workaround of unplugging the HDMI cable and plugging again seems to work. After I plug the cable again the RAM usage drops by 10-15 GB at once.
I noticed a lot of memory seems to be allocated by the NVIDIA driver somehow. I ran 'sudo pmap -x $(pidof kwin_wayland)' immediately before and after doing the workaround above. When I compared both outputs, there were many (> 5000) memory mappings labelled 'nvidiactl' that vanished after I plugged the cable back again.
$ diff -W 200 --color=always -y ./kwin_wayland.pmap.before_unplug_plug.txt ./kwin_wayland.pmap.after_unplug_plug.txt | grep '<' | awk '{ print $6 }' | sort | uniq -c
5 [
3 card0
1 card1
3 memfd:gdk-wayland
4 memfd:wayland-shm
5247 nvidiactl
I'll be happy to provide more information about my system or run any more debugging commands to help diagnosing the problem if needed.
I can confirm I have the same issue. When I boot my laptop kwin_wayland process normally uses about 70MB of RAM and then over time while I use my laptop with my Samsung CRG9 49' external monitor the memory keeps growing until everything freezes. For me the issue manifests a bit differently, so apologies if I should report this as a separate ticket instead. But it is instability involving multiple monitors in KDE 6. After turning monitors off and back on, either from power management settings or from manual power button push, sometimes video playback by any application (vlc, firefox, etc.) freezes the entire desktop for 30-60 seconds before updating the desktop once then freezing again until playback is paused/stops. Memory usage by kwin_wayland and plasmashell stay the same (about 400 MB and 600 MB respectively) during this time. kwin_wayland --replace does not help the issue, but pkill kwin_wayland and logging back in does. I did not experience the issue initially when I first installed Arch in January on I believe one of the last versions of KDE 5 to be shipped with it, and started noticing the issue some time after the upgrade to KDE 6. SYSTEM Arch running kernel 6.13.7-arch1-1 CPU: Ryzen 7 9700X GPU: AMD ATI Radeon RX 7900 XT Monitors: Sceptre M27 at 1920x1080@120Hz (non-primary); Gigabyte M28U at 3840x2160@144Hz (primary) $ pacman -Qi kwin Name : kwin Version : 6.3.3.1-1 STEPS TO REPRODUCE (for my specific hardware) Type 1: 1. Turn off primary display. Secondary display flashes, a device disconnect chime is heard, menubar on secondary display vanishes briefly. 2. Turn off secondary display. Device connect chime (from primary monitor) is heard. 3. Turn on secondary display. Disconnect and connect chime is heard. 4. Turn on primary display. Secondary display flashes, disconnect chime, menubar flicker, connect chime. 5. If unlucky, any video playback (vlc, firefox etc.) causes display freeze. Type 2: 1. Turn off primary display. Secondary display flashes, a device disconnect chime is heard, menubar on secondary display vanishes briefly, device connect chime is heard, menubar reappears with another minor flicker. 2. Turn on primary display. Secondary display flashes, disconnect chime, menubar flicker, connect chime, etc. 3. If unlucky, any video playback (vlc, firefox etc.) causes display freeze. LOG INFO In being able to force the type 2 scenario above from repeated power toggling, this is what was output to journalctl from primary display poweroff through the video playback freeze: Mar 23 10:27:09 Menphina org_kde_powerdevil[74224]: [ 81069] Removing connected display on bus 8 Mar 23 10:27:09 Menphina org_kde_powerdevil[74224]: [ 81069] Emitting DDCA_Display_Status_Event[939.372: DDCA_EVENT_DISPLAY_DISCONNECTED, card1-DP-1, dref: DDCA_Display_Ref[14], io_path:/dev/i2c-8, ddc working: false] Mar 23 10:27:09 Menphina org_kde_powerdevil[74224]: [ 81069] libddcutil callback thread 0x7926a401f770 started Mar 23 10:27:09 Menphina org_kde_powerdevil[74224]: [ 81069] Started 1 event callback thread(s) Mar 23 10:27:11 Menphina org_kde_powerdevil[74224]: [ 81069] Adding connected display with bus 8 Mar 23 10:27:11 Menphina org_kde_powerdevil[74224]: [ 81069] Emitting DDCA_Display_Status_Event[941.095: DDCA_EVENT_DISPLAY_CONNECTED, card1-DP-1, dref: DDCA_Display_Ref[15], io_path:/dev/i2c-8, ddc working: true] Mar 23 10:27:11 Menphina org_kde_powerdevil[74224]: [ 81069] libddcutil callback thread 0x7926a401a430 started Mar 23 10:27:11 Menphina org_kde_powerdevil[74224]: [ 81069] Started 1 event callback thread(s) Mar 23 10:27:11 Menphina org_kde_powerdevil[74224]: [ 74224] Quiescing libddcutil API... Mar 23 10:27:11 Menphina org_kde_powerdevil[74224]: [ 74224] Quiesce libddcutil API complete Mar 23 10:27:11 Menphina org_kde_powerdevil[74224]: [ 74224] Display redetection starting. Mar 23 10:27:11 Menphina org_kde_powerdevil[74224]: [ 81068] recheck thread terminating because watch thread terminated Mar 23 10:27:11 Menphina org_kde_powerdevil[74224]: [ 74224] Watch thread terminated. Mar 23 10:27:12 Menphina org_kde_powerdevil[74224]: [ 74224] Watching for display connection changes, resolved watch mode = Watch_Mode_Xevent, poll loop interval = 100 millisec Mar 23 10:27:12 Menphina org_kde_powerdevil[74224]: [ 74224] extra_stabilization_millisec: 0, stabilization_poll_millisec: 100 Mar 23 10:27:12 Menphina org_kde_powerdevil[74224]: [ 74224] libddcutil recheck thread (nil) started Mar 23 10:27:12 Menphina org_kde_powerdevil[74224]: [ 74224] libddcutil watch thread 0x600a3af462d0 started Mar 23 10:27:12 Menphina org_kde_powerdevil[74224]: [ 74224] Display redetection finished. Mar 23 10:27:12 Menphina org_kde_powerdevil[74224]: [ 74224] Unquiescing libddcutil API... Mar 23 10:27:12 Menphina org_kde_powerdevil[74224]: [ 81375] (dw_recheck_displays_func) Recheck interval: Slept for 200 millisec Mar 23 10:27:16 Menphina org_kde_powerdevil[74224]: [ 81376] Removing connected display on bus 8 Mar 23 10:27:16 Menphina org_kde_powerdevil[74224]: [ 81376] Emitting DDCA_Display_Status_Event[945.787: DDCA_EVENT_DISPLAY_DISCONNECTED, card1-DP-1, dref: DDCA_Display_Ref[17], io_path:/dev/i2c-8, ddc working: false] Mar 23 10:27:16 Menphina org_kde_powerdevil[74224]: [ 81376] libddcutil callback thread 0x7926a0014860 started Mar 23 10:27:16 Menphina org_kde_powerdevil[74224]: [ 81376] Started 1 event callback thread(s) Mar 23 10:27:17 Menphina org_kde_powerdevil[74224]: [ 81376] Adding connected display with bus 8 Mar 23 10:27:18 Menphina org_kde_powerdevil[74224]: [ 81376] Emitting DDCA_Display_Status_Event[947.662: DDCA_EVENT_DISPLAY_CONNECTED, card1-DP-1, dref: DDCA_Display_Ref[18], io_path:/dev/i2c-8, ddc working: true] Mar 23 10:27:18 Menphina org_kde_powerdevil[74224]: [ 81376] libddcutil callback thread 0x7926a00062a0 started Mar 23 10:27:18 Menphina org_kde_powerdevil[74224]: [ 81376] Started 1 event callback thread(s) Mar 23 10:27:18 Menphina org_kde_powerdevil[74224]: [ 74224] Quiescing libddcutil API... Mar 23 10:27:21 Menphina org_kde_powerdevil[74224]: Error queiscing libdducitl API. 1 active API calls outstanding. Mar 23 10:27:21 Menphina org_kde_powerdevil[74224]: [ 74224] Error queiscing libdducitl API. 1 active API calls outstanding. Mar 23 10:27:21 Menphina org_kde_powerdevil[74224]: org.kde.powerdevil: [DDCutilDisplay]: ddca_close_display -3032 Mar 23 10:27:21 Menphina org_kde_powerdevil[74224]: library quiesced, ddca_close_display temporarily unavailable Mar 23 10:27:21 Menphina org_kde_powerdevil[74224]: [ 74224] Display redetection starting. Mar 23 10:27:21 Menphina org_kde_powerdevil[74224]: [ 81375] recheck thread terminating because watch thread terminated Mar 23 10:27:21 Menphina org_kde_powerdevil[74224]: [ 74224] Watch thread terminated. Mar 23 10:27:21 Menphina org_kde_powerdevil[74224]: [ 74224] Attempting to unlock display lock owned by different thread Mar 23 10:27:21 Menphina org_kde_powerdevil[74224]: [ 74224] Unexpected error DDCRC_LOCKED from unlock_display_by_dpath(Display_Path[/dev/i2c-6]) Mar 23 10:27:52 Menphina kwin_wayland[73944]: kwin_wayland_drm: The main thread was hanging temporarily! Most times I experience the issue nothing much is emitted to journalctl. I have noticed something weird about this bug. After unplugging and plugging my monitors back in, kwin only happens to leak memory (for me) when moving the mouse on a monitor directly connected to the nvidia gpu, and it also comes with momentary cpu usage spikes (to 20-30% usage from a normal 5%). (In reply to LucasGGamerM from comment #71) > I have noticed something weird about this bug. After unplugging and plugging > my monitors back in, kwin only happens to leak memory (for me) when moving > the mouse on a monitor directly connected to the nvidia gpu, and it also > comes with momentary cpu usage spikes (to 20-30% usage from a normal 5%). I did some more testing, and it appears to happen movement happens on the monitors connected to the nvidia gpu, not just mouse movements. Any updates on this issue? Maybe any workaround? Kinda bad that i need to unplug my monitor 3-6 times a day. If any info is needed to understand problems cause, provide me guide how to get this requiered info, so i can provide it to you. Thanks! (In reply to Vlad Zabotinsky from comment #73) > Any updates on this issue? Maybe any workaround? Kinda bad that i need to > unplug my monitor 3-6 times a day. If any info is needed to understand > problems cause, provide me guide how to get this requiered info, so i can > provide it to you. Thanks! Just do kwin_wayland --replace everytime you encounter this issue. It's not great and keep in mind most of your applications will be closed, but at least the memory leak won't happen until the next time you unplug and replug your monitor. (In reply to righn from comment #74) > (In reply to Vlad Zabotinsky from comment #73) > > Any updates on this issue? Maybe any workaround? Kinda bad that i need to > > unplug my monitor 3-6 times a day. If any info is needed to understand > > problems cause, provide me guide how to get this requiered info, so i can > > provide it to you. Thanks! > > Just do kwin_wayland --replace everytime you encounter this issue. It's not > great and keep in mind most of your applications will be closed, but at > least the memory leak won't happen until the next time you unplug and replug > your monitor. Difficult to call it a workaround, if you have to close and reopen your apps several times per day (happens, if you walk with your laptop or put it to sleep, connecting and disconnecting it from external monitors). the issue seems gone with Linux 6.14 from Archlinux core-testing. `kwin_wayland` RSS around 800mb, with 2 screens connected to the AMD iGPU and 1 to a NVIDIA 4060ti the problem seems gone with Linux 6.14 from Archlinux core-testing. kwin_wayland RSS stable ~800mb, with 2 4k screens connected to AMD iGPU and 1 4k screen to NVIDIA 4060ti Created attachment 179739 [details]
signature.asc
Promising... Which nvidia driver version are you on?
> Created attachment 179739 [details]
> signature.asc
Oops, forgot you shouldn't reply with signed emails on bugzilla...
(In reply to righn from comment #74) > (In reply to Vlad Zabotinsky from comment #73) > > Any updates on this issue? Maybe any workaround? Kinda bad that i need to > > unplug my monitor 3-6 times a day. If any info is needed to understand > > problems cause, provide me guide how to get this requiered info, so i can > > provide it to you. Thanks! > > Just do kwin_wayland --replace everytime you encounter this issue. It's not > great and keep in mind most of your applications will be closed, but at > least the memory leak won't happen until the next time you unplug and replug > your monitor. Unfortunately this isn't good workaround for me, because i have more than 10 windows of different apps opened simultaneously. To open them 6 times a day is out of question. (I have laptop, so unplug monitor is much faster). (In reply to tmpod from comment #78) > Created attachment 179739 [details] > signature.asc > > Promising... Which nvidia driver version are you on? Driver Version: 570.124.04 Kernel: 6.13.6-1-default Installed it from Nvidia .run file in OpenSuse TW. I was replying to Bráulio, but more info is always good :) After a bit of testing, it seems that in this report there are many separate issues, with similar symptoms - memory leak. Some people report that replugging the monitors temporarily resolves the issue, but I cannot confirm this; for me the only way that the issue can be resolved is to simply reboot. Also there is a discussion about kernel versions and in the thread there was mentioned that downgrading to 6.6 LTS fixes the issue, however again I cannot confirm this (maybe anybody else can?). I've not managed to test out the 6.14 kernel to try out if it resolves. May I suggest to create some kind of "checklist" from all the information in this issue to better group people with the same actual problem and symptoms, and from there we can create separate reports and focus more on the individual problems and their origin (as well as if the source is kwin, kernel etc.)? Is there anyone from the dev team/community who would be able to create such checklist? Hi I'm having this issue as well. I'm adding a comment as another temporary workaround is to log out / log back in. Hope this helps someone. Still, here's some system info, just in case.: Operating System: Arch Linux KDE Plasma Version: 6.3.3 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.2 Kernel Version: 6.13.8-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 7735HS with Radeon Graphics Memory: 14.9 GiB of RAM Graphics Processor 1: AMD Radeon 680M Graphics Processor 2: NVIDIA Corporation AD107M System Version: 1.0 Cheers :) For me it was like the shr mem was increasing every second a couple of MB, when the content of the screen changed. So lets say you are on the browser scrolling this thread, and with every htop refresh, the memory increased.
I was trying to get some insights stracing kwin_wayland, as it was anoying me quite often, but it seems i couldn't reproduce anymore after updating today..
My idea was to try soemthing like sudo strace -Ttvff -o strace_log -e trace=mmap,munmap,mremap -k -p $(pidof kwin_wayland)
but Im not sure either it would be of help...
For nowwith new version installed it ram is steady on 262MB of SHR 402M of Res.
Nevermind... connecting / disconnecting the screen started raising the memory once again, but if you stop scrolling, it sometimes frees some memory... I'll try to gather the strace and see if it is of worth... (after a couple of mintues of writing and scroll here, 633M)
My Specs
pacman -Qi kwin
Nombre : kwin
Versión : 6.3.3.1-1
Descripción : An easy to use, but flexible, composited Window Manager
Arquitectura : x86_64
NAME="EndeavourOS"
BUILD_ID="2024.09.22"
Operating System:
KDE Plasma Version: 6.3.3
Qt Version: 6.8.2-3
Kernel Version: 6.12.20-1-lts
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 9 7940HS w/ Radeon 780M Graphics
Memory: 30 GiB of RAM
Graphics Processor: AMD Radeon 780M
inxi -G
Graphics:
Device-1: NVIDIA AD106M [GeForce RTX 4070 Max-Q / Mobile] driver: nvidia
v: 570.133.07
Device-2: Advanced Micro Devices [AMD/ATI] Phoenix1 driver: amdgpu
v: kernel
Device-3: Sonix USB2.0 HD UVC WebCam driver: uvcvideo type: USB
Device-4: USB C Video Adaptor driver: N/A type: USB
Display: wayland server: X.Org v: 24.1.6 with: Xwayland v: 24.1.6
compositor: kwin_wayland driver: X: loaded: amdgpu,nvidia
unloaded: modesetting dri: radeonsi gpu: amdgpu,nvidia,nvidia-nvswitch
resolution: 1: 2400x1350~100Hz 2: 1920x1080~144Hz
API: EGL v: 1.5 drivers: kms_swrast,nvidia,radeonsi
platforms: gbm,wayland,x11,surfaceless,device
API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: amd mesa v: 25.0.2-arch1.2
renderer: AMD Radeon 780M (radeonsi phoenix LLVM 19.1.7 DRM 3.61
6.12.20-1-lts)
API: Vulkan v: 1.4.309 drivers: N/A surfaces: xcb,xlib,wayland
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console,
kscreen-doctor, xfce4-display-settings gpu: nvidia-smi wl: nwg-displays,
swaymsg, wayland-info x11: xdpyinfo, xprop, xrandr
ok, for my setup, just ftr the external monitor is 1920*1080 and the rate of increase (measured just with htop) is about 4M per second while scrolling this page up/down fast (sometimes it is 6M but mostly it is 4M). Idk how to attach the outputs here, but I can tell that at least for me, this mmap seems not being freed in the short term (couple of minutes), not sure if it helps anyways, weird enough, it only happens with the external monitor 22:37:54 mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_SHARED, 368, 0) = 0x7e0325000000 <0.000079> > /usr/lib/libc.so.6(__mmap+0x2c) [0x115d4c] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xec3b0b] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xec418d] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xec85b3] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xad3d4e] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xa31158] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xa32f1c] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xa333b1] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xa8c9cc] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xa87d73] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xa73d4c] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xaf87f4] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xafc2bb] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xab0f53] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xb961dc] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xa457f7] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0x9fdddd] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xa20f92] > /usr/lib/libEGL_nvidia.so.570.133.07() [0x3b561] > /usr/lib/libEGL_nvidia.so.570.133.07() [0x3bd67] > /usr/lib/libEGL_nvidia.so.570.133.07() [0x4e2cc] > /usr/lib/libEGL.so.1.1.0() [0x4cfd] > /usr/lib/libEGL.so.1.1.0(eglMakeCurrent+0x103) [0x7403] > /usr/lib/libkwin.so.6.3.3(KWin::EglContext::makeCurrent(void*)+0x56) [0x2669e6] > /usr/lib/libkwin.so.6.3.3() [0x426074] > /usr/lib/libkwin.so.6.3.3() [0x426bbe] > /usr/lib/libkwin.so.6.3.3() [0x4270b1] > /usr/lib/libkwin.so.6.3.3() [0x17c2b7] > /usr/lib/libQt6Core.so.6.8.2() [0x1b1a49] > /usr/lib/libkwin.so.6.3.3() [0x1907e5] > /usr/lib/libkwin.so.6.3.3(KWin::RenderLoopPrivate::dispatch()+0x23) [0x1958d3] > /usr/lib/libQt6Core.so.6.8.2() [0x1b1a49] > /usr/lib/libQt6Core.so.6.8.2(QTimer::timerEvent(QTimerEvent*)+0xa5) [0x1baa75] > /usr/lib/libQt6Core.so.6.8.2(QObject::event(QEvent*)+0xe9) [0x1a2ef9] > /usr/lib/libQt6Widgets.so.6.8.2() [0xff0ca] > /usr/lib/libQt6Core.so.6.8.2() [0x155b00] > /usr/lib/libQt6Core.so.6.8.2(QTimerInfoList::activateTimers()+0x5df) [0x2d5aff] > /usr/lib/libQt6Core.so.6.8.2() [0x2de408] > /usr/lib/libQt6Gui.so.6.8.2() [0x661d93] > /usr/lib/libQt6Core.so.6.8.2() [0x1606a6] > /usr/lib/libQt6Core.so.6.8.2(QCoreApplication::exec()+0xa6) [0x1591d6] > /usr/bin/kwin_wayland() [0x4006e] > /usr/lib/libc.so.6() [0x27488] > /usr/lib/libc.so.6(__libc_start_main+0x8c) [0x2754c] > /usr/bin/kwin_wayland() [0x463d5] --- now kwin_wayland has 8G of shared mem, so running strace caused all ui to freeze, but fine sudo strace -Ttvff -o strace_free -e trace=mmap,munmap,mremap,process,clone,memory,brk,fork -k -p $(pidof kwin_wayland) strace: Process 1278 attached with 36 threads strace: Process 36109 attached strace: Process 36110 attached strace: Process 36111 attached strace: Process 36141 attached strace: Process 36142 attached strace: Process 36143 attached strace: Process 36325 attached strace: Process 36326 attached strace: Process 36327 attached strace: Process 36432 attached strace: Process 36433 attached strace: Process 36434 attached strace: Process 36465 attached strace: Process 36466 attached strace: Process 36467 attached strace: Process 36468 attached strace: Process 36472 attached strace: Process 36473 attached strace: Process 36474 attached strace: Process 36475 attached strace: Process 36476 attached strace: Process 36477 attached strace: Process 36478 attached strace: Process 36479 attached strace: Process 36480 attached strace: Process 36482 attached strace: Process 36483 attached strace: Process 36484 attached strace: Process 36486 attached strace: Process 36527 attached strace: Process 36528 attached strace: Process 36571 attached strace: Process 36572 attached strace: Process 36573 attached strace: Process 36575 attached strace: Process 36576 attached strace: Process 36577 attached strace: Process 36579 attached strace: Process 36580 attached strace: Process 36581 attached strace: Process 36600 attached strace: Process 36601 attached strace: Process 36602 attached strace: Process 36603 attached strace: Process 36604 attached strace: Process 36605 attached strace: Process 36654 attached strace: Process 36667 attached strace: Process 36668 attached strace: Process 36704 attached strace: Process 36705 attached strace: Process 36706 attached strace: Process 36707 attached strace: Process 36708 attached strace: Process 36710 attached strace: Process 36711 attached strace: Process 36714 attached strace: Process 36715 attached strace: Process 36716 attached strace: Process 36717 attached strace: Process 36718 attached strace: Process 36719 attached strace: Process 36720 attached strace: Process 36721 attached strace: Process 36722 attached strace: Process 36723 attached strace: Process 36724 attached strace: Process 36726 attached strace: Process 36734 attached strace: Process 36735 attached strace: Process 36744 attached strace: Process 36754 attached strace: Process 36805 attached strace: Process 36831 attached strace: Process 36831 detached strace: Process 36754 detached strace: Process 36744 detached strace: Process 36726 detached strace: Process 36724 detached strace: Process 36723 detached strace: Process 36719 detached strace: Process 36711 detached strace: Process 36710 detached strace: Process 36708 detached strace: Process 36654 detached strace: Process 36486 detached strace: Process 36484 detached strace: Process 36483 detached strace: Process 36482 detached strace: Process 36474 detached strace: Process 36473 detached strace: Process 36472 detached strace: Process 36468 detached strace: Process 36467 detached strace: Process 36466 detached strace: Process 36465 detached strace: Process 36434 detached strace: Process 36433 detached strace: Process 36432 detached strace: Process 36327 detached strace: Process 21796 detached strace: Process 21795 detached strace: Process 1353 detached strace: Process 1352 detached strace: Process 1348 detached strace: Process 1346 detached strace: Process 1345 detached strace: Process 1344 detached strace: Process 1343 detached strace: Process 1342 detached strace: Process 1328 detached strace: Process 1324 detached strace: Process 1323 detached strace: Process 1322 detached strace: Process 1321 detached strace: Process 1320 detached strace: Process 1319 detached strace: Process 1318 detached strace: Process 1317 detached strace: Process 1316 detached strace: Process 1315 detached strace: Process 1314 detached strace: Process 1313 detached strace: Process 1312 detached strace: Process 1311 detached strace: Process 1310 detached strace: Process 1309 detached strace: Process 1307 detached strace: Process 1278 detached ... and I can see lots (3960) of 23:21:25 munmap(0x7e014a200000, 2097152) = 0 <0.000043> > /usr/lib/libc.so.6(__munmap+0xb) [0x11670b] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xec39c5] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xec44b3] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xad27d7] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xad2a99] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xa3214b] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xa3267a] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0xab0bee] > /usr/lib/libnvidia-eglcore.so.570.133.07() [0x75c89b] > /usr/lib/libkwin.so.6.3.3() [0x424863] > /usr/lib/libkwin.so.6.3.3() [0x426bbe] > /usr/lib/libkwin.so.6.3.3() [0x42821a] > /usr/lib/libkwin.so.6.3.3() [0x428a36] > /usr/lib/libkwin.so.6.3.3() [0x428bfd] > /usr/lib/libkwin.so.6.3.3() [0x429517] > /usr/lib/libkwin.so.6.3.3() [0x41cd8b] > /usr/lib/libkwin.so.6.3.3() [0x4388a1] > /usr/lib/libkwin.so.6.3.3() [0x43967b] > /usr/lib/libkwin.so.6.3.3() [0x43995a] > /usr/lib/libkwin.so.6.3.3() [0x43ad99] > /usr/lib/libkwin.so.6.3.3() [0x42e5a2] > /usr/lib/libkwin.so.6.3.3() [0x42e17d] > /usr/lib/libkwin.so.6.3.3() [0x42e17d] > /usr/lib/libkwin.so.6.3.3() [0x42eccc] > /usr/lib/libkwin.so.6.3.3() [0x4324e7] > /usr/lib/libkwin.so.6.3.3() [0x40dc0e] > /usr/lib/libkwin.so.6.3.3() [0x391ea5] > /usr/lib/libkwin.so.6.3.3() [0x3922fb] > /usr/lib/libkwin.so.6.3.3() [0x392be3] > /usr/lib/libQt6Core.so.6.8.2() [0x1b1a49] > /usr/lib/libkwin.so.6.3.3(KWin::DrmBackend::updateOutputs()+0x663) [0x40e673] > /usr/lib/libkwin.so.6.3.3(KWin::DrmBackend::handleUdevEvent()+0x3e4) [0x410594] > /usr/lib/libQt6Core.so.6.8.2() [0x1b1a49] > /usr/lib/libQt6Core.so.6.8.2(QSocketNotifier::event(QEvent*)+0x488) [0x1bbf08] > /usr/lib/libQt6Widgets.so.6.8.2() [0xff0ca] > /usr/lib/libQt6Core.so.6.8.2() [0x155b00] > /usr/lib/libQt6Core.so.6.8.2() [0x2d70d8] > /usr/lib/libQt6Core.so.6.8.2() [0x2de712] > /usr/lib/libQt6Gui.so.6.8.2() [0x661d93] > /usr/lib/libQt6Core.so.6.8.2() [0x1606a6] > /usr/lib/libQt6Core.so.6.8.2(QCoreApplication::exec()+0xa6) [0x1591d6] > /usr/bin/kwin_wayland() [0x4006e] > /usr/lib/libc.so.6() [0x27488] > /usr/lib/libc.so.6(__libc_start_main+0x8c) [0x2754c] > /usr/bin/kwin_wayland() [0x463d5] Not sure if it helps or if anyone need additional info, happy to help Regarding toggling fullscreen, For me it increases SHR in 2M each event, and of course there is a slight increase on CPU on the threads tagged with HDMI-A-1. For now my workaround is to periodically switch the KVM to another monitor (which will unplug the laptops external monitor) :/ this effectively frees SHR memory. not sure how can be related, but after setting KWIN_DRM_DISABLE_TRIPLE_BUFFERING=true and loging out and in again, it seems a little bit more stable in terms of shared memory TLDR: the easiest way to free the memory and stop for a while the problem:
THIS WILL CLOSE ALL NON-KDE APPS, BE CAREFUL
`kwin_wayland replace`
After that, DONT disconnect the external monitor to avoid the issue, avoid it going to sleep mode too if possible. Force the computer to not sleep.
I'm facing this issue too, it starts happening after I disconnect and connect my external monitor.
```
Operating System: Fedora Linux 41
KDE Plasma Version: 6.3.3
KDE Frameworks Version: 6.12.0
Qt Version: 6.8.2
Kernel Version: 6.13.8-200.fc41.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × 11th Gen Intel® Core™ i7-11800H @ 2.30GHz
Memory: 62.5 GiB of RAM
Graphics Processor 1: Mesa Intel® UHD Graphics
Graphics Processor 2: llvmpipe
Manufacturer: Redacted
Product Name: Redacted
```
I notice this errors when plugging and unplugging the monitor:
```
Mar 26 22:49:54 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 22:50:00 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 22:56:00 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 22:56:00 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 22:56:00 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 22:56:01 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 22:56:01 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 23:32:32 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 23:32:33 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 27 00:10:56 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
Mar 27 00:10:56 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 27 00:14:32 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
Mar 27 00:14:32 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 27 00:17:37 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 27 00:18:32 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
Mar 27 00:18:32 fedora kwin_wayland[2185]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
```
Additionally, a bunch of stuff crashes, if the monitor is sleeping and I login back:
```
Mar 26 10:22:20 fedora kernel: usb 3-2.3: device descriptor read/64, error -32
Mar 26 10:22:20 fedora kernel: usb 3-2.3: device descriptor read/64, error -32
Mar 26 10:22:20 fedora kernel: usb 3-2.3: device descriptor read/64, error -32
Mar 26 10:22:20 fedora kernel: usb 3-2.3: device descriptor read/64, error -32
Mar 26 10:22:20 fedora kernel: usb 3-2.3: device not accepting address 13, error -71
Mar 26 10:22:20 fedora kernel: usb 3-2.3: device not accepting address 14, error -71
Mar 26 10:22:20 fedora kernel: usb 3-2-port3: unable to enumerate USB device
Mar 26 10:22:14 fedora systemd-modules-load[397]: Failed to find module 'vhba'
Mar 26 13:22:22 fedora kernel:
Mar 26 13:22:23 fedora bluetoothd[1114]: Failed to set mode: Failed (0x03)
Mar 26 13:22:24 fedora systemd-coredump[1479]: Process 545 (plymouthd) of user 0 dumped core.
...
Mar 26 15:30:20 fedora kwin_wayland[2173]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 15:51:57 fedora kwin_wayland[2173]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 15:52:03 fedora kwin_wayland[2173]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 21:05:56 fedora org_kde_powerdevil[2410]: Attempting to unlock display lock owned by different thread
Mar 26 21:05:56 fedora org_kde_powerdevil[2410]: Unexpected error DDCRC_LOCKED from unlock_display_by_dpath(Display_Path[/dev/i2c-16])
Mar 26 21:05:57 fedora systemd-coredump[404565]: Process 2410 (org_kde_powerde) of user 1001 dumped core.
...
Mar 26 21:05:58 fedora kwin_wayland[2173]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
Mar 26 21:05:58 fedora kwin_wayland[2173]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 21:06:00 fedora abrt-notification[404736]: Process 2340 (org_kde_powerdevil) crashed in _nl_load_domain.cold()
Mar 26 21:06:04 fedora systemd-coredump[404655]: Process 2344 (plasmashell) of user 1001 dumped core.
...
Mar 26 21:06:14 fedora abrt-notification[405233]: Process 2275 (plasmashell) crashed in KCrash::defaultCrashHandler(int)()
Mar 26 21:09:29 fedora kwin_wayland[2173]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
Mar 26 21:09:29 fedora kwin_wayland[2173]: kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
Mar 26 21:09:31 fedora systemd-coredump[407276]: Process 404890 (plasmashell) of user 1001 dumped core.
```
I am also having this issue. Fedora Linux 41 (KDE Spin) Plasma 6.3.3 KDE Frameworks 6.12.0 Qt 6.8.2 Kernel 6.13.7-200fc41.x86_64 (64 bit) Wayland Nvidia RTX A1000 with driver 570.124.04 (although it started happening months ago on older drivers) It only happens with my external monitor connected, after the display has turned off (note - I don't believe it is true sleep as that is disabled). My external monitor is 3440x1440, 144 Hz, with adaptive sync, color profiles, and HDR disabled. Color accuracy is set to "Prefer efficiency" and the monitor is connected to the Nvidia GPU via USB-C --> Lenovo Dock --> Display Port on monitor. As mentioned above, logging out and back in, unplugging the cable and re-plugging, or kwin_wayland --replace all drop the memory back down to base consumption. Also as mentioned above, moving the mouse does seem to spike CPU usage. I have been noticing this on my system too. 30Gb of reserved memory to the kwin_wayland process. Internal monitor has a scaling factor of 33.33%, external monitor is 4K, scaled to 150%, and connected to the HDMI port of the laptop. I believe this wired through the Advanced Optimus MUX. Both iGPU and dGPU are active. System details: Operating System: Arch Linux KDE Plasma Version: 6.3.3 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.3 Kernel Version: 6.13.7-arch1-1.2-g14 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7945HX3D with Radeon Graphics Memory: 62.0 GiB of RAM Graphics Processor 1: AMD Radeon 610M Graphics Processor 2: NVIDIA GeForce RTX 4090 Laptop GPU Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Strix G733PYV_G733PYV System Version: 1.0 Has anyone tried to check with Hotspot [1], where the memory is being allocated over time in kwin_wayland to get a hint? [1] https://github.com/KDAB/hotspot Sorry, I meant heaptrack: https://github.com/KDE/heaptrack I did, but couldn't find what the issue is (skill issue here) I'm attaching the heaptrack here, note the reserved memory grows, but the actual issue at least for me is the shared memory buffer, and it only grows if there is something new to update the contents of the screen, if you have the external monitor connected (and leaking) but it is "still" (nothing to update the screen contents with), you'll not notice the increase of memory consumption. Heaptrack: https://paste.c-net.org/RaditchLanterns Streaces: https://paste.c-net.org/GrownStormy To add another data point for people who are looking into this one... When connecting to the external monitor through a USB-C to DisplayPort adapter, the issue is not present, so it would seem to be localized only to when the external monitor is connected directly to the HDMI port of the laptop. So, there may be a workaround where you can connect your external monitor to a laptop docking hub. (In reply to Evert Vorster from comment #94) > To add another data point for people who are looking into this one... > When connecting to the external monitor through a USB-C to DisplayPort > adapter, the issue is not present, so it would seem to be localized only to > when the external monitor is connected directly to the HDMI port of the > laptop. > > So, there may be a workaround where you can connect your external monitor to > a laptop docking hub. In my case, monitor is already connected to a Dell WD15 dock using the HDMI port on it and the dock is connected to a USB-C port and I still have this issue. SUMMARY / OBSERVATION When playing games with external monitor connected and on, Kwin_Wayland increasingly uses all of the memory until system is at 100% usage and then the system locks up. System memory usage increases until system locks up and must be powered off. 'kwin_wayland --replace' is the quick (messy) fix or a reboot. The problem resumes as soon as the memory is cleared if system is used with an external monitor. I have done some testing withOUT an external display in a couple of games, eg Counter-Strike 2 and have observed memory usage is normal, ie, it increases somewhat during game and drops off after exiting game. SOFTWARE/OS VERSIONS/HARDWARE Operating System: Garuda Linux KDE Plasma Version: 6.3.3 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.3 Kernel Version: 6.13.8-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800H with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor 1: AMD Radeon Graphics Graphics Processor 2: NVIDIA GeForce RTX 3060 Laptop GPU Manufacturer: ASUSTeK COMPUTER INC. Product Name: ASUS TUF Gaming A15 FA506QM_TUF506QM System Version: 1.0 Screens: 1. built in laptop 2. AOC CQ27G4 Monitor (USB C <-> DP) 3. SONY BRAVIA TV (HDMI) *** Bug 502259 has been marked as a duplicate of this bug. *** (In reply to righn from comment #95) > (In reply to Evert Vorster from comment #94) > > To add another data point for people who are looking into this one... > > When connecting to the external monitor through a USB-C to DisplayPort > > adapter, the issue is not present, so it would seem to be localized only to > > when the external monitor is connected directly to the HDMI port of the > > laptop. > > > > So, there may be a workaround where you can connect your external monitor to > > a laptop docking hub. > > In my case, monitor is already connected to a Dell WD15 dock using the HDMI > port on it and the dock is connected to a USB-C port and I still have this > issue. Can confirm that what I initially thought was a workaround is not, in fact, working. I have also seen memory leak on my USB-C to DisplayPort adapter in use. (In reply to tmpod from comment #78) > Created attachment 179739 [details] > signature.asc > > Promising... Which nvidia driver version are you on? latest from Arch, 570.133.07, https://archlinux.org/packages/extra-testing/x86_64/nvidia/ For what it's worth, when using the 6.14 kernel this issue seems to be gone. I'm currently running linux-mainline on Arch. I spoke too soon, after a suspend-resume cycle, I could see the memory counting up in kwin_wayland just sitting there, with nothing happening on screen. So, false alarm, 6.14 kernel does not, in fact, cure this issue. I just had this happen I think. Kwin_wayland was eating 46GB of shared memory, system was really feeling it too, closed the process and it restarted with normal usage (330mb or so). Bit annoying, am using 4090 with open-nvidia drivers 6.14 kernel (cachyos) In case anyone was wondering, 6.3.4 did not fix this issue. (In reply to Evert Vorster from comment #101) > I spoke too soon, after a suspend-resume cycle, I could see the memory > counting up in kwin_wayland just sitting there, with nothing happening on > screen. > > So, false alarm, 6.14 kernel does not, in fact, cure this issue. Can you check if this issue occurs to you if on the 6.6 LTS kernel? (In reply to Chan from comment #104) > (In reply to Evert Vorster from comment #101) > Can you check if this issue occurs to you if on the 6.6 LTS kernel? I'm a bit reluctant to run such an old kernel, my hardware is pretty new, and using features in the 6.13 kernel to operate properly. Currently running 6.13-g14 kernel which interfaces nicely with the other Asus tools. Anyways, I have now downgraded my nVidia drivers to 550.144 dkms. The reason for this is that nVidia seems to be a common factor here, and its worth a try. So far, the memory usage of kwin_wayland has been steady, but I will run it for a while to see if the problem before I report any successes. Created attachment 180079 [details] attachment-8514-0.html i noticed the bug only triggers once external monitor is unplugged then replugged in. Then kwin will start consuming more and more memory, about 100mb per minute here, as long as the external monitor screen keeps getting updated. Heaptrack does not report any leak. As mentionned earlier, workarounds include unpluggin then replugging the external monitor (resets memory but keeps leaking); or restarting kwin altogether (prevent the leak until monitor unplugged/replugged again). On Mon, Apr 7, 2025 at 9:52 PM Evert Vorster <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=496469 > > --- Comment #105 from Evert Vorster <evorster@protonmail.com> --- > (In reply to Chan from comment #104) > > (In reply to Evert Vorster from comment #101) > > Can you check if this issue occurs to you if on the 6.6 LTS kernel? > I'm a bit reluctant to run such an old kernel, my hardware is pretty new, > and > using features in the 6.13 kernel to operate properly. > Currently running 6.13-g14 kernel which interfaces nicely with the other > Asus > tools. > > Anyways, I have now downgraded my nVidia drivers to 550.144 dkms. The > reason > for this is that nVidia seems to be a common factor here, and its worth a > try. > So far, the memory usage of kwin_wayland has been steady, but I will run > it for > a while to see if the problem before I report any successes. > > -- > You are receiving this mail because: > You are on the CC list for the bug. Downgrading to nVidia 550.144 dkms in Arch definitely cured the issue for me. System has gone through sleep cycles, had it's external monitor unplugged and plugged back in again. kwin_wayland is sitting at 377Mb of memory usage and stays there. Sometimes going up a little, and then back down, depending on what I am doing with the system. In my case, at least, the cause definitely appears to be the nVidia drivers doing something different than they used to do, and this seems to confuse kwin_wayland. Indeed, I remember that NVIDIA 550 was the last one that worked for me. Been running for a few hours now, and with nVidia 550.144 kwin_wayland's memory usage is absolutely stable. One notable code path that is not in the 550.144 is HDR, which I am kind of missing. Looking through this report there is also no mention of Gnome or other compositors, and nVidia is mentioned in every report. This further strengthens the idea that there is something that the newer nVidia drivers are doing that kwin_wayland is not expecting, or not handling properly. Unfortunately, this does not look like it is going to go away unless kwin_wayland makes some changes. I can also confirm that switching to nvidia driver version 550.144.03 memory leaks seems to be gone. After a bit of googling I found this on nvidia forums: https://forums.developer.nvidia.com/t/extreme-growing-memory-usage-in-x11-opengl-or-vulkan-applications-after-suspend-resume/329078 However they talk about X11 and not Wayland specifically, so might not be related; however I provide the link anyway if anyone wants to do further research. (In reply to charly ghislain from comment #106) > > i noticed the bug only triggers once external monitor is unplugged then > replugged in. Then kwin will start consuming more and more memory, about > 100mb per minute here, as long as the external monitor screen keeps getting > updated. Heaptrack does not report any leak. > I suspect, the same happens when your computer goes into sleep mode due to inactivity with dual monitor setup. I disabled the sleep while AC connected and since then `kwin_wayland` has been stable. But i can't confirm it 100%. Unfortunately for me, it was leaking even without a suspend/resume cycle. I have recently updated the firmware on my external monitor, and it fixed a some other issues I was having, so I will test again with the latest nVidia drivers to see if there is any improvements there. Just confirmed that this issue is still present in the 570 version of the nvidia drivers, even after the monitor's firmware update, and HDR on. > i noticed the bug only triggers once external monitor is unplugged then
> replugged in. Then kwin will start consuming more and more memory, about
> 100mb per minute here, as long as the external monitor screen keeps getting
> updated. Heaptrack does not report any leak.
I tried monitoring kwin_wayland's memory and it stays at 483MiB right now, and as soon as I turn off and turn my monitor back on. The memory usage keep increasing. I noticed a weird one. If my external screen updates, either by moving mouse, etc. It will increase the memory faster than when it's on idle and no changes. But it still increasing, but slow.
I'll try downgrading to 550.144, and I will try upgrading from that version.
nope, i cannot downgrade, it will just reject ``` /usr/lib/libnvidia-egl-gbm.so exists in both 'nvidia-utils' and 'egl-gbm' /usr/lib/libnvidia-egl-gbm.so.1 exists in both 'nvidia-utils' and 'egl-gbm' /usr/share/egl/egl_external_platform.d/15_nvidia_gbm.json exists in both 'nvidia-utils' and 'egl-gbm' ``` Shouldn't we file a bug on nvidia repo? (In reply to barra from comment #115) > nope, i cannot downgrade, it will just reject > ``` > /usr/lib/libnvidia-egl-gbm.so exists in both 'nvidia-utils' and 'egl-gbm' > /usr/lib/libnvidia-egl-gbm.so.1 exists in both 'nvidia-utils' and 'egl-gbm' > /usr/share/egl/egl_external_platform.d/15_nvidia_gbm.json exists in both > 'nvidia-utils' and 'egl-gbm' > ``` Yes, uninstall nvidia-utils and egl-gbm. Then when you install the older nvidia, it will bring in a different dependency. (In reply to barra from comment #116) > Shouldn't we file a bug on nvidia repo? First, we have to figure out what the issue is. Other window managers does not seem to have this problem, so the signs are pointing to the issue being in kwin_wayland. It only happens with NVidia, and only with newer driver versions. That doesn't necessarily mean it's a driver bug, but it's not unlikely, and we're not getting anywhere here either way. (In reply to barra from comment #116) > Shouldn't we file a bug on nvidia repo? I've already pinged a NVidia developer about this issue, but having a bug report to track on their side would probably be good. You can open one here: https://forums.developer.nvidia.com/c/gpu-graphics/linux (In reply to Evert Vorster from comment #117) > (In reply to barra from comment #115) > > nope, i cannot downgrade, it will just reject > > ``` > > /usr/lib/libnvidia-egl-gbm.so exists in both 'nvidia-utils' and 'egl-gbm' > > /usr/lib/libnvidia-egl-gbm.so.1 exists in both 'nvidia-utils' and 'egl-gbm' > > /usr/share/egl/egl_external_platform.d/15_nvidia_gbm.json exists in both > > 'nvidia-utils' and 'egl-gbm' > > ``` > > Yes, uninstall nvidia-utils and egl-gbm. Then when you install the older > nvidia, it will bring in a different dependency. from the aur right? nvidia-550xx-dkms, for some reason it failed for me ==> dkms install --no-depmod nvidia/550.144.03 -k 6.14.1-zen1-1-zen Error! Bad return status for module build on kernel: 6.14.1-zen1-1-zen (x86_64) Consult /var/lib/dkms/nvidia/550.144.03/build/make.log for more information. ==> WARNING: `dkms install --no-depmod nvidia/550.144.03 -k 6.14.1-zen1-1-zen' exited 10 So I'll stay with the latest version (570), I'll just block "Sleep and Screen Locking after Inactivity" (In reply to barra from comment #120) > (In reply to Evert Vorster from comment #117) > > (In reply to barra from comment #115) > > > nope, i cannot downgrade, it will just reject > > > ``` > > > /usr/lib/libnvidia-egl-gbm.so exists in both 'nvidia-utils' and 'egl-gbm' > > > /usr/lib/libnvidia-egl-gbm.so.1 exists in both 'nvidia-utils' and 'egl-gbm' > > > /usr/share/egl/egl_external_platform.d/15_nvidia_gbm.json exists in both > > > 'nvidia-utils' and 'egl-gbm' > > > ``` > > > > Yes, uninstall nvidia-utils and egl-gbm. Then when you install the older > > nvidia, it will bring in a different dependency. > > from the aur right? nvidia-550xx-dkms, for some reason it failed for me > > ==> dkms install --no-depmod nvidia/550.144.03 -k 6.14.1-zen1-1-zen > > Error! Bad return status for module build on kernel: 6.14.1-zen1-1-zen > (x86_64) > Consult /var/lib/dkms/nvidia/550.144.03/build/make.log for more information. > ==> WARNING: `dkms install --no-depmod nvidia/550.144.03 -k > 6.14.1-zen1-1-zen' exited 10 > > So I'll stay with the latest version (570), I'll just block "Sleep and > Screen Locking after Inactivity" With the danger of going way off topic here... Did you know that the zen kernel is not aimed at the zen architecture? You are better off running just plain arch kernel on AMD CPU if the zen kernel is incompatible with the older nvidia drivers. (In reply to Evert Vorster from comment #121) > (In reply to barra from comment #120) > > (In reply to Evert Vorster from comment #117) > > > (In reply to barra from comment #115) > > > > nope, i cannot downgrade, it will just reject > > > > ``` > > > > /usr/lib/libnvidia-egl-gbm.so exists in both 'nvidia-utils' and 'egl-gbm' > > > > /usr/lib/libnvidia-egl-gbm.so.1 exists in both 'nvidia-utils' and 'egl-gbm' > > > > /usr/share/egl/egl_external_platform.d/15_nvidia_gbm.json exists in both > > > > 'nvidia-utils' and 'egl-gbm' > > > > ``` > > > > > > Yes, uninstall nvidia-utils and egl-gbm. Then when you install the older > > > nvidia, it will bring in a different dependency. > > > > from the aur right? nvidia-550xx-dkms, for some reason it failed for me > > > > ==> dkms install --no-depmod nvidia/550.144.03 -k 6.14.1-zen1-1-zen > > > > Error! Bad return status for module build on kernel: 6.14.1-zen1-1-zen > > (x86_64) > > Consult /var/lib/dkms/nvidia/550.144.03/build/make.log for more information. > > ==> WARNING: `dkms install --no-depmod nvidia/550.144.03 -k > > 6.14.1-zen1-1-zen' exited 10 > > > > So I'll stay with the latest version (570), I'll just block "Sleep and > > Screen Locking after Inactivity" > > With the danger of going way off topic here... Did you know that the zen > kernel is not aimed at the zen architecture? > You are better off running just plain arch kernel on AMD CPU if the zen > kernel is incompatible with the older nvidia drivers. yea... ok that the name "zen" is not related to zen arch. I use the zen kernel for uhh "additional benefit that they offer" and mostly binder module for waydroid (well the plain kernel now support it soo), idk never bother to switch kernel The bug may relate to multi-GPU copy mode. I changed the "display NV DDS Function" settings in BIOS from "MsHybrid" to "dGPU only". The problem does not happen anymore. Before that, `wayland-info | grep INTEL` returned something and `wayland-info | grep NVIDIA` returned nothing. (Memory leak happened) After that , `wayland-info | grep NVIDIA` returns something and `wayland-info | grep INTEL` returns nothing. (Memory leak does not happen here anymore, after testing for one day). System: Arch Linux Kernel: 6.14.2-arch1-1 kwin version: 6.3.4-4 (Arch Linux package version number) Graphics Platform: Wayland Qt Version: 6.9.0 (In reply to Neod from comment #123) > The bug may relate to multi-GPU copy mode. > I changed the "display NV DDS Function" settings in BIOS from "MsHybrid" to > "dGPU only". The problem does not happen anymore. > Before that, `wayland-info | grep INTEL` returned something and > `wayland-info | grep NVIDIA` returned nothing. (Memory leak happened) > After that , `wayland-info | grep NVIDIA` returns something and > `wayland-info | grep INTEL` returns nothing. (Memory leak does not happen > here anymore, after testing for one day). > > System: Arch Linux > Kernel: 6.14.2-arch1-1 > kwin version: 6.3.4-4 (Arch Linux package version number) > Graphics Platform: Wayland > Qt Version: 6.9.0 I can confirm, this fixed the issue on my Lenovo Thinkpad with an RTX A1000 and integrated Intel GPU. It also made my external monitor much more responsive. The downside is that it broke a couple things, like Zoom screensharing. Turning off the iGPU is not an option on laptops. Sure, it is technically possible, but the entire point of having an iGPU is to conserve power. With the 550 series of nVidia drivers this memory leak does not happen with using the iGPU and dGPU in an Advanced Optimus setup. For me the current workaround this issue is to use the 550 series of nVidia drivers, but this is hardly a long term solution. There are some other remaining issues with the nVidia drivers that are later than 550, like not properly waking up an external monitor if its refresh rate is over 30Hz, but it seems that only kwin_wayland has a memory leak with the later nVidia drivers, and other display managers do not seem to have this issue with the later drivers. As expected, running old drivers now is a problem. OBS studio disables nvenc on the 550 version of drivers now, claiming that it is out of date. Can confirm that kwin_wayland is still leaking like a sieve. On my system it does not even need to have gone through a suspend/resume cycle, it just leaks at an alarming rate. Created attachment 180743 [details] attachment-2827128-0.html Likewise it can leak very quickly on my system during normal, that is, loading various things into RAM. If however I'm watching a film for example it can go a long time because there is little exchange of contents in RAM. No suspend/resume required, only using external monitor is required. I haven't tried old drivers. On Tue, 29 Apr 2025, 04:55 Evert Vorster, <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=496469 > > --- Comment #126 from Evert Vorster <evorster@protonmail.com> --- > As expected, running old drivers now is a problem. > OBS studio disables nvenc on the 550 version of drivers now, claiming that > it > is out of date. > > Can confirm that kwin_wayland is still leaking like a sieve. On my system > it > does not even need to have gone through a suspend/resume cycle, it just > leaks > at an alarming rate. > > -- > You are receiving this mail because: > You are on the CC list for the bug. Does this bug still happen on a new user account? (In reply to steadily_dismount201 from comment #128) > Does this bug still happen on a new user account? I have since re-installed Arch, and created a new user account. This appears to have solved the issue for me. Spoke too soon again! Having a new user account somewhat alleviated the issue, but it is still there. With an hour of usage after a screen power off and on, I can see the memory usage creep up again. kwin_wayland usually uses about 500MB of memory on my system, and it is now nearing 1GB (In reply to Evert Vorster from comment #130) > Spoke too soon again! > Having a new user account somewhat alleviated the issue, but it is still > there. > With an hour of usage after a screen power off and on, I can see the memory > usage creep up again. > kwin_wayland usually uses about 500MB of memory on my system, and it is now > nearing 1GB Try playing a video with a lot of movement in the external monitor, that usually makes the memory usage grow more noticeably Can confirm that when the system is in dGPU only mode, this issue is gone. My system supports three different graphics modes, Integrated, Hybrid and AsusMuxDgpu. With Integrated mode, the nVidia card is switched off, and so the external monitor does not work. In Hybrid mode, the dGPU drives the external monitor through the HDMI port and the iGPU drives the internal monitor. The dGPU also does render offloading to the laptop's panel if needed. So, when I plug in the external monitor, the dGPU fires up anyways, and no power saving benefits are to be had there. On the last mode, the nVidia dGPU drives both the monitors and does the compositing too. The AMD GPU sits mostly idle. Since this issue only pops up when the external monitor is connected in Hybrid mode, and the dGPU fires up in any case to drive the external monitor, AsusMuxDgpu mode is an acceptable workaround for me while the external monitor is connected. It is easy enough to switch with supergfxctl, an no fannying around in the BIOS is needed, just a set and reboot command. Created attachment 181016 [details] attachment-2251139-0.html Well spotted Evert. I thought I would give that a try too. In my case however with my ASUS TUF A15 the option to only use the Discrete GPU is not available with SuperGfxCtl, nor in BIOS, only the integrated option is available. My system is a Prime set up that chooses the GPU automatically so perhaps that may have something to do with it. While I'm typing, I'll mention I have just received the 6.14.5 kernel and the memory leaks seem to be happening much much faster. Just a few minutes and I can be at 80% used memory. On Mon, May 5, 2025 at 11:35 AM Evert Vorster <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=496469 > > --- Comment #132 from Evert Vorster <evorster@protonmail.com> --- > Can confirm that when the system is in dGPU only mode, this issue is gone. > > My system supports three different graphics modes, Integrated, Hybrid and > AsusMuxDgpu. > > With Integrated mode, the nVidia card is switched off, and so the external > monitor does not work. > In Hybrid mode, the dGPU drives the external monitor through the HDMI port > and > the iGPU drives the internal monitor. The dGPU also does render offloading > to > the laptop's panel if needed. > So, when I plug in the external monitor, the dGPU fires up anyways, and no > power saving benefits are to be had there. > > On the last mode, the nVidia dGPU drives both the monitors and does the > compositing too. The AMD GPU sits mostly idle. > > Since this issue only pops up when the external monitor is connected in > Hybrid > mode, and the dGPU fires up in any case to drive the external monitor, > AsusMuxDgpu mode is an acceptable workaround for me while the external > monitor > is connected. > It is easy enough to switch with supergfxctl, an no fannying around in the > BIOS > is needed, just a set and reboot command. > > -- > You are receiving this mail because: > You are on the CC list for the bug. (In reply to Nick H from comment #133) > Created attachment 181016 [details] > attachment-2251139-0.html > > Well spotted Evert. > > I thought I would give that a try too. In my case however with my ASUS TUF > A15 the option to only use the Discrete GPU is not available with > SuperGfxCtl, nor in BIOS, only the integrated option is available. My > system is a Prime set up that chooses the GPU automatically so perhaps that > may have something to do with it. > > While I'm typing, I'll mention I have just received the 6.14.5 kernel and > the memory leaks seem to be happening much much faster. Just a few minutes > and I can be at 80% used memory. Hi Nick. I checked online, and your laptop does not have a MUX switch, so the option to just use the dGPU for everything is not available. This is because the dGPU is simply not wired to any output. My wife's laptop, a very similar Asus TUF A15 with a slightly different AMD cpu also does not have the mux switch. What are the chances? It is also running Arch linux, and just been updated. It is running in Hybrid mode, and I can confirm that only Integrated and Hybrid modes are available in supergfxctl. What is very interesting is that there does not appear to be a memory leak in kwin_wayland on that laptop. I've been watching it for a while, and can confirm that kwin_wayland's memory consumption is sitting dead still at 330Mb. That laptop is connected to an external screen as well, but only 1080p at 60Hz refresh rate. How are you driving your external monitor, what resolutions and refresh rates are you using? I have a hunch that this might be related to the resolution/refresh rates that some higher end external monitors are capable of. I don't know much about programming, but this might just be a buffer that is sufficient for lower resolutions and then blows up when you really push it. One interesting thing I just found out it's that the series of the nvidia driver which introduced explicit sync support on wayland was nvidia driver 555, and the latest known non memory leaking driver version is 550, that may be a hint that there is something going wrong with nvidia's and/or kwin's explicit sync implementation. can anyone confirm, that the hack below temporarily fixes the issue? https://github.com/NVIDIA/egl-wayland/issues/126#issuecomment-2379945259 i got the memory leak also when external monitor was switch off by power management. and now i tested both unplugging the cable and waiting for the power management to take over. for me the memory leak seams to be gone. ``` OS: Manjaro Linux x86_64 Host: GF65 Thin 10SDR (REV:1.0) CPU: Intel(R) Core(TM) i7-10750H (12) @ 5.00 GHz GPU 1: NVIDIA GeForce GTX 1660 Ti Mobile [Discrete] GPU 2: Intel UHD Graphics @ 1.15 GHz [Integrated] NVIDIA 570.144 ``` (In reply to Tanel Tammik from comment #136) > can anyone confirm, that the hack below temporarily fixes the issue? > > https://github.com/NVIDIA/egl-wayland/issues/126#issuecomment-2379945259 > > i got the memory leak also when external monitor was switch off by power > management. and now i tested both unplugging the cable and waiting for the > power management to take over. for me the memory leak seams to be gone. > > ``` > OS: Manjaro Linux x86_64 > Host: GF65 Thin 10SDR (REV:1.0) > CPU: Intel(R) Core(TM) i7-10750H (12) @ 5.00 GHz > GPU 1: NVIDIA GeForce GTX 1660 Ti Mobile [Discrete] > GPU 2: Intel UHD Graphics @ 1.15 GHz [Integrated] > NVIDIA 570.144 > ``` i am sorry for spamming. this does not solve anything. Created attachment 181047 [details] attachment-2578341-0.html Ahh that's interesting that we have two very similar setups (your wife's & mine) and potentially we could learn something here. I'm connected to a 2560x1440 AOC monitor via USB-c to display port cable, running at 144 hz, which is the same RR as my laptop screen. The laptop is 1080p 144hz but I keep it turned off via the OS. Ok so after writing that I decided to do some testing with my ext. monitor at 1080p@60hz. An hour on Cyberpunk 2077 and then Kwin was using only 490mb. Impressive. I thought it was fixed. I tried some CS2, but from there Kwin jumped up 1 and then 2gb. I played another low system requirements game that added more. Then I did some quick gaming at 1440p@144hz and kwins usage increased much quicker. I concluded that running at 1080p@60hz does not fix the problem but does reduce (or turn the tap down on) the memory leaking significantly. On Thu, 8 May 2025, 02:59 Evert Vorster, > Hi Nick. > I checked online, and your laptop does not have a MUX switch, so the > option to > just use the dGPU for everything is not available. > This is because the dGPU is simply not wired to any output. > > My wife's laptop, a very similar Asus TUF A15 with a slightly different > AMD cpu > also does not have the mux switch. > What are the chances? > > It is also running Arch linux, and just been updated. It is running in > Hybrid > mode, and I can confirm that only Integrated and Hybrid modes are > available in > supergfxctl. > > What is very interesting is that there does not appear to be a memory leak > in > kwin_wayland on that laptop. I've been watching it for a while, and can > confirm > that kwin_wayland's memory consumption is sitting dead still at 330Mb. > That laptop is connected to an external screen as well, but only 1080p at > 60Hz > refresh rate. > > How are you driving your external monitor, what resolutions and refresh > rates > are you using? > I have a hunch that this might be related to the resolution/refresh rates > that > some higher end external monitors are capable of. I don't know much about > programming, but this might just be a buffer that is sufficient for lower > resolutions and then blows up when you really push it. > > -- > You are receiving this mail because: > You are on the CC list for the bug. With a heavy heart, I am coming back to GNOME. While KDE is far more responsive, GNOME is at least stable. Restarting almost all programs a few times per day, as is the case with KDE, destroys the workflow. The sad thing is that while bugs happen, it does not seem like KDE developers are interested in fixing this one, despite the fact that it is very serious, easily reproducible, affects a significant number of people and was reported half a year ago. Created attachment 181202 [details] attachment-670598-0.html Yes Gnome is very stable generally. I migrated over from Gnome to KDE and love plasma's power and flexibility but I have noticed more bugs. Generally the developers at KDE are very good at fixing them quite quickly. This is one of the few bugs I've been involved with logging that seems to have very little developer feedback and yet is fairly serious (but then I don't know who in this discussion is a developer and who is not). Perhaps they have been unable to isolate the issue so far. On Mon, 12 May 2025, 21:25 Lech, <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=496469 > > --- Comment #139 from Lech <misc@lwp.email> --- > With a heavy heart, I am coming back to GNOME. While KDE is far more > responsive, GNOME is at least stable. Restarting almost all programs a few > times per day, as is the case with KDE, destroys the workflow. > > The sad thing is that while bugs happen, it does not seem like KDE > developers > are interested in fixing this one, despite the fact that it is very > serious, > easily reproducible, affects a significant number of people and was > reported > half a year ago. > > -- > You are receiving this mail because: > You are on the CC list for the bug. (In reply to Nick H from comment #140) > Created attachment 181202 [details] > attachment-670598-0.html > > Yes Gnome is very stable generally. I migrated over from Gnome to KDE and > love plasma's power and flexibility but I have noticed more bugs. Generally > the developers at KDE are very good at fixing them quite quickly. This is > one of the few bugs I've been involved with logging that seems to have very > little developer feedback and yet is fairly serious (but then I don't know > who in this discussion is a developer and who is not). Perhaps they have > been unable to isolate the issue so far. > Perhaps. The problem then is a lack of communication. In the current state, I have no idea if they are ignoring the issue, working on it, and the solution is almost there, or working on it, but unable to isolate the issue, etc. Thus, no idea if KDE will be stable for me in 1 week, 1 month, 1 year or never... The logical thing to do is to move to a stable environment, despite its shortcomings. As I said, with a heavy heart. We really do understand the frustration people have with long standing bugs like this. It's frustrating for us as well when we can't reproduce something and Just Fix It.
With that said, please keep discussion of this bug related to the bug itself. Straying into tangents and trying to guess what other people are thinking only clutters up the report and makes it more confusing.
To get this back on track, here are the details that stand out. The problem occurs on:
- Single or multi-GPU systems
- Seen with GPUs: AMD, Nvidia, Intel
- A common cause is displays waking up / being added
Workaround:
Unplugging the HDMI / display cable and plugging it back in indeed causes the memory to be released
Alternatively run
kwin_wayland --replace
What would be most helpful for us at this point is to get some performance data during high memory usage. This will give us insight into which parts of the code are causing the problem. If anyone wants to do this, you can use `perf`. You can get `perf` from a package usually called something like `linux-tools` from your distro. After you install that, run this while the memory leak is happening:
```bash
sudo perf record -F 1000 -p $(pidof kwin_wayland) -g -- sleep 6
```
You can then view a report you can copy and paste. This will be generated based on the `perf.data` file from the last step. Run this:
```
sudo perf report
```
Another thing that would be helpful for us is if someone could get us a flamegraph of kwin_wayland while it's using a high amount of memory, if anyone has set up the tools for that.
I'm attempting to replicate this again right now, although I've tried in the last month or so and not seen the problem. I have a system similar to a few of the people experiencing the bug. It's a Dell XPS with an Intel iGPU and nVidia dGPU plugged into a dock. There are two monitors connected to the dock, one over DP and the other over HDMI. I unplugged the HDMI cable and plugged it back in, since that's triggered the bug for at least one person. I have ran the instructions provided by TraceyC, and so far, with 3.8 gigs leaked, here is the "sudo perf report" output, I hope it is useful. ``` Samples: 886 of event 'cycles:P', Event count (approx.): 2804897302 Children Self Command Shared Object Symbol + 68,17% 0,00% kwin_wayland kwin_wayland [.] 0x00005574b81d5495 ◆ + 68,17% 0,00% kwin_wayland libc.so.6 [.] __libc_start_main@@GLIBC_2.34 ▒ + 68,17% 0,00% kwin_wayland libc.so.6 [.] __libc_start_call_main ▒ + 68,17% 0,00% kwin_wayland kwin_wayland [.] 0x00005574b81cefeb ▒ + 68,17% 0,00% kwin_wayland libQt6Core.so.6.9.0 [.] QCoreApplication::exec() ▒ + 68,17% 0,00% kwin_wayland libQt6Core.so.6.9.0 [.] QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ▒ + 68,17% 0,00% kwin_wayland libQt6Gui.so.6.9.0 [.] QUnixEventDispatcherQPA::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ▒ + 67,58% 0,12% kwin_wayland libQt6Core.so.6.9.0 [.] QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ▒ + 56,26% 0,00% kwin_wayland libQt6Core.so.6.9.0 [.] QCoreApplication::notifyInternal2(QObject*, QEvent*) ▒ + 56,26% 0,00% kwin_wayland libQt6Widgets.so.6.9.0 [.] QApplicationPrivate::notify_helper(QObject*, QEvent*) ▒ + 55,91% 0,00% kwin_wayland libQt6Core.so.6.9.0 [.] 0x00007ff99ab6033a ▒ + 45,92% 0,00% kwin_wayland libQt6Core.so.6.9.0 [.] QTimerInfoList::activateTimers() ▒ + 45,46% 0,00% kwin_wayland libQt6Core.so.6.9.0 [.] QObject::event(QEvent*) ▒ + 45,16% 0,00% kwin_wayland libQt6Core.so.6.9.0 [.] QTimer::timeout(QTimer::QPrivateSignal) ▒ + 45,16% 0,12% kwin_wayland libkwin.so.6.3.5 [.] KWin::RenderLoopPrivate::dispatch() ▒ + 45,04% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::RenderLoop::frameRequested(KWin::RenderLoop*) ▒ + 44,24% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::WaylandCompositor::composite(KWin::RenderLoop*) ▒ + 41,01% 0,28% kwin_wayland [kernel.kallsyms] [k] entry_SYSCALL_64_after_hwframe ▒ + 40,68% 0,26% kwin_wayland [kernel.kallsyms] [k] do_syscall_64 ▒ + 25,15% 0,00% kwin_wayland libc.so.6 [.] __GI___ioctl ▒ + 24,79% 0,09% kwin_wayland [kernel.kallsyms] [k] __x64_sys_ioctl ▒ + 23,14% 0,14% kwin_wayland libdrm.so.2.124.0 [.] drmIoctl ▒ + 21,67% 0,14% kwin_wayland [kernel.kallsyms] [k] drm_ioctl ▒ + 21,24% 0,00% kwin_wayland [kernel.kallsyms] [k] drm_ioctl_kernel ▒ + 16,45% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::Compositor::paintPass(KWin::RenderLayer*, KWin::RenderTarget const&, QRegion const&) ▒ + 16,33% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::SceneDelegate::paint(KWin::RenderTarget const&, QRegion const&) ▒ + 16,33% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::WorkspaceScene::paint(KWin::RenderTarget const&, QRegion const&) ▒ + 15,27% 0,00% kwin_wayland [kernel.kallsyms] [k] nvkms_call_rm ▒ + 14,90% 0,00% kwin_wayland [kernel.kallsyms] [k] nvKmsIoctl ▒ + 14,84% 0,00% kwin_wayland libkwin.so.6.3.5 [.] 0x00007ff99db488a7 ▒ + 14,51% 0,00% kwin_wayland [kernel.kallsyms] [k] nvkms_ioctl_from_kapi ▒ + 14,37% 0,00% kwin_wayland libkwin.so.6.3.5 [.] 0x00007ff99db483e1 ▒ + 12,89% 0,11% kwin_wayland libc.so.6 [.] __syscall_cancel_arch_end ▒ + 12,85% 0,00% kwin_wayland libc.so.6 [.] __syscall_cancel ▒ + 11,63% 0,00% kwin_wayland libkwin.so.6.3.5 [.] 0x00007ff99db51fc4 ▒ + 11,63% 0,00% kwin_wayland libdrm.so.2.124.0 [.] drmModeAddFB2WithModifiers ▒ + 11,51% 0,00% kwin_wayland [kernel.kallsyms] [k] drm_mode_addfb2 ▒ + 11,51% 0,00% kwin_wayland [kernel.kallsyms] [k] drm_internal_framebuffer_create ▒ + 11,49% 0,00% kwin_wayland libkwin.so.6.3.5 [.] 0x00007ff99db469e5 ▒ + 11,24% 0,00% kwin_wayland [kernel.kallsyms] [k] nv_drm_framebuffer_create ▒ + 11,24% 0,00% kwin_wayland [kernel.kallsyms] [k] nv_drm_internal_framebuffer_create ▒ + 11,24% 0,00% kwin_wayland [kernel.kallsyms] [k] nv_drm_framebuffer_init ▒ + 11,24% 0,00% kwin_wayland [kernel.kallsyms] [k] CreateSurface ▒ + 11,24% 0,00% kwin_wayland [kernel.kallsyms] [k] RegisterSurface ▒ + 11,24% 0,00% kwin_wayland [kernel.kallsyms] [k] nvEvoRegisterSurface ▒ + 10,70% 0,00% kwin_wayland libQt6Core.so.6.9.0 [.] QEventDispatcherUNIXPrivate::activateSocketNotifiers() ▒ + 9,71% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::EffectsHandler::paintScreen(KWin::RenderTarget const&, KWin::RenderViewport const&, int, QRegion const&, KWin::Output*) ▒ + 9,42% 0,00% kwin_wayland libQt6Core.so.6.9.0 [.] QSocketNotifier::event(QEvent*) ▒ + 9,42% 0,00% kwin_wayland libQt6Core.so.6.9.0 [.] QSocketNotifier::activated(QSocketDescriptor, QSocketNotifier::Type, QSocketNotifier::QPrivateSignal) ▒ + 9,39% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::WorkspaceScene::paintSimpleScreen(KWin::RenderTarget const&, KWin::RenderViewport const&, int, QRegion const&) ▒ + 9,29% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::WorkspaceScene::paintWindow(KWin::RenderTarget const&, KWin::RenderViewport const&, KWin::WindowItem*, int, QRegion const&) ▒ + 9,29% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::EffectsHandler::paintWindow(KWin::RenderTarget const&, KWin::RenderViewport const&, KWin::EffectWindow*, int, QRegion const&, KWin::WindowPaintData&) ▒ + 9,29% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::AnimationEffect::paintWindow(KWin::RenderTarget const&, KWin::RenderViewport const&, KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) ▒ + 9,29% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::EffectsHandler::drawWindow(KWin::RenderTarget const&, KWin::RenderViewport const&, KWin::EffectWindow*, int, QRegion const&, KWin::WindowPaintData&) ▒ + 9,02% 0,00% kwin_wayland [kernel.kallsyms] [k] _nv04ControlWithSecInfo ▒ + 9,02% 0,00% kwin_wayland [kernel.kallsyms] [k] rmapiControlWithSecInfoTls ▒ + 8,95% 0,00% kwin_wayland [kernel.kallsyms] [k] nvRmApiControl ▒ + 8,82% 0,00% kwin_wayland [kernel.kallsyms] [k] Nv04ControlKernel ▒ + 8,81% 0,00% kwin_wayland [kernel.kallsyms] [k] rmapiControlWithSecInfo ▒ + 8,81% 0,00% kwin_wayland [kernel.kallsyms] [k] _rmapiRmControl ▒ + 8,67% 0,00% kwin_wayland libQt6Core.so.6.9.0 [.] qt_safe_poll(pollfd*, unsigned long, QDeadlineTimer) ▒ + 8,43% 0,00% kwin_wayland libc.so.6 [.] ppoll ▒ + 8,03% 0,00% kwin_wayland [kernel.kallsyms] [k] nvRmAllocAndBindSurfaceDescriptor ▒ + 7,96% 0,15% kwin_wayland [kernel.kallsyms] [k] __x64_sys_ppoll ▒ + 7,38% 0,00% kwin_wayland [kernel.kallsyms] [k] nvCtxDmaBind ▒ + 7,30% 0,14% kwin_wayland [kernel.kallsyms] [k] do_sys_poll ▒ + 7,13% 0,00% kwin_wayland libkwin.so.6.3.5 [.] 0x00007ff99db4cb5c ▒ + 7,13% 0,00% kwin_wayland libdrm.so.2.124.0 [.] drmHandleEvent ▒ + 6,78% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::CrossFadeEffect::drawWindow(KWin::RenderTarget const&, KWin::RenderViewport const&, KWin::EffectWindow*, int, QRegion const&, KWin::WindowPaintData&) ▒ + 6,53% 0,12% kwin_wayland libkwin.so.6.3.5 [.] KWin::ItemRendererOpenGL::renderItem(KWin::RenderTarget const&, KWin::RenderViewport const&, KWin::Item*, int, QRegion const&, KWin::WindowPaintData const&) ▒ + 5,66% 0,60% kwin_wayland [kernel.kallsyms] [k] do_poll.constprop.0 ▒ + 5,64% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::ItemRendererOpenGL::endFrame() ▒ + 5,63% 0,14% kwin_wayland [kernel.kallsyms] [k] serverControl ▒ + 5,54% 0,00% kwin_wayla:cs0 libc.so.6 [.] __GI___clone3 ▒ + 5,54% 0,00% kwin_wayla:cs0 libc.so.6 [.] start_thread ▒ + 5,54% 0,00% kwin_wayla:cs0 libgallium-25.0.4.so [.] 0x00007ff97d74064c ▒ + 5,51% 0,00% kwin_wayland libkwin.so.6.3.5 [.] KWin::DrmOutput::present(std::shared_ptr<KWin::OutputFrame> const&) ▒ + 5,16% 0,00% DP-2 libc.so.6 [.] __GI___clone3 ▒ + 5,16% 0,00% DP-2 libc.so.6 [.] start_thread ▒ + 5,16% 0,00% DP-2 libQt6Core.so.6.9.0 [.] 0x00007ff99acbdde4 ▒ + 5,16% 0,00% DP-2 libQt6Core.so.6.9.0 [.] 0x00007ff99ac21dd7 ▒ + 5,16% 0,00% DP-2 libkwin.so.6.3.5 [.] 0x00007ff99db34c23 ▒ + 5,16% 0,00% DP-2 libc.so.6 [.] pthread_once@GLIBC_2.2.5 ▒ + 5,16% 0,00% DP-2 libc.so.6 [.] __pthread_once_slow.isra.0 ▒ + 5,16% 0,00% DP-2 libkwin.so.6.3.5 [.] 0x00007ff99db34176 ▒ + 5,16% 0,00% DP-2 libkwin.so.6.3.5 [.] 0x00007ff99db39c8a ▒ + 4,92% 0,00% DP-2 [kernel.kallsyms] [k] entry_SYSCALL_64_after_hwframe ``` I'm not able to reproduce the memory leak on git-master. Observations after a few hours: kwin_wayland started with 246Mib usage, 451MiB resident, 1.6% CPU. After using the system normally, using Firefox, VM Manager, Thunderbird, FreeTube, Obsidian Notes - I saw resident memory go as high as 515MiB, drop, raise and drop again. Right now it's sitting at 455MiB. (In reply to LucasGGamerM from comment #144) > I have ran the instructions provided by TraceyC, and so far, with 3.8 gigs > leaked, here is the "sudo perf report" output, I hope it is useful. Thank you for providing that. This report is set to high priority, so hopefully one of the KWin developers can take a further look at this in the near future. (In reply to TraceyC from comment #146) > (In reply to LucasGGamerM from comment #144) > > I have ran the instructions provided by TraceyC, and so far, with 3.8 gigs > > leaked, here is the "sudo perf report" output, I hope it is useful. > > Thank you for providing that. This report is set to high priority, so > hopefully one of the KWin developers can take a further look at this in the > near future. One thing of notice that my copy and paste did not include, and that I just noticed through putting both the normal kwin stack and the leaking kwin stack side by side in flamegraph was that the leaky kwin had a lot more "blocks" in their flamegraph graph. What I mean is that the stack in the leaky kwin is around 20-30 times bigger in terms of filesize when compared to a normal kwin stack, and it also looked like every function had made a bunch of instances of itself over and over again. I can share the graphs and the stack trace if requested, I tried sharing directly in a comment, but I think files are not allowed. To reproduce the bug in my machine: 1. In BIOS, use hybrid mode. See my previous comment https://bugs.kde.org/show_bug.cgi?id=496469#c123 2. kwin_wayland start with 250-270MB of memory. 3. meta + L to lock the screen and wait for the screen to turn off. (In power management, set turn off screen to `When locked: 20 second`, just to trigger the memory leaking.) 4. Then just wake up the screen, do anything and wait for 10 - 15 mins. The memory used by kwin_wayland will goes up to 500-1G. To just provide some hardware settings, a. CPU and GPU: i9-13900H+4060 Laptop GPU, b. built-in screen is 2500x1600 240Hz, and my external screen is 3840x2160 60Hz connected through HDMI. I also try setting the refresh rate of the built-in screen to 60Hz, but memory leak is still there. i. driver for iGPU: I tried both i915 and xe. And both do not avoid the bug. ii. early loading: I also try early loading `i915` `xe` `nvidia`module and so on in various combinations and orders in `mkinitcpio`. But none of them avoid the bug. My workaround now is to set `Turn off screen` to `Never` and select `Do nothing` `when inactive` in `System settings - Power management`. I'm adding a flame here https://mega.nz/file/tlcGGQZC#TvSljPKj6-N6yV0MVDP2yZJx1RB_6B0otwGWbOHf1Sg Created attachment 181241 [details]
perf report from kwin_wayland while memory leak
Tue May 13 11:14:26 CEST 2025
PID VSZ RSS CMD
4669 3677220 1527716 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 --xwayland-xauthority /run/user/1000/xauth_SAasxU --xwayland
Tue May 13 11:24:26 CEST 2025
PID VSZ RSS CMD
4669 3846936 1713144 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 --xwayland-xauthority /run/user/1000/xauth_SAasxU --xwayland
Tue May 13 11:34:26 CEST 2025
PID VSZ RSS CMD
4669 4083372 1931404 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 --xwayland-xauthority /run/user/1000/xauth_SAasxU --xwayland
Tue May 13 11:44:26 CEST 2025
PID VSZ RSS CMD
4669 4468184 2257200 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 --xwayland-xauthority /run/user/1000/xauth_SAasxU --xwayland
Tue May 13 11:54:26 CEST 2025
PID VSZ RSS CMD
4669 4896956 2684612 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 --xwayland-xauthority /run/user/1000/xauth_SAasxU --xwayland
Happy hunting mates!
(In reply to Zolv from comment #150) > Created attachment 181241 [details] > perf report from kwin_wayland while memory leak > > Tue May 13 11:14:26 CEST 2025 > PID VSZ RSS CMD > 4669 3677220 1527716 /usr/bin/kwin_wayland --wayland-fd 7 --socket > wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 > --xwayland-xauthority /run/user/1000/xauth_SAasxU --xwayland > Tue May 13 11:24:26 CEST 2025 > PID VSZ RSS CMD > 4669 3846936 1713144 /usr/bin/kwin_wayland --wayland-fd 7 --socket > wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 > --xwayland-xauthority /run/user/1000/xauth_SAasxU --xwayland > Tue May 13 11:34:26 CEST 2025 > PID VSZ RSS CMD > 4669 4083372 1931404 /usr/bin/kwin_wayland --wayland-fd 7 --socket > wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 > --xwayland-xauthority /run/user/1000/xauth_SAasxU --xwayland > Tue May 13 11:44:26 CEST 2025 > PID VSZ RSS CMD > 4669 4468184 2257200 /usr/bin/kwin_wayland --wayland-fd 7 --socket > wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 > --xwayland-xauthority /run/user/1000/xauth_SAasxU --xwayland > Tue May 13 11:54:26 CEST 2025 > PID VSZ RSS CMD > 4669 4896956 2684612 /usr/bin/kwin_wayland --wayland-fd 7 --socket > wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 > --xwayland-xauthority /run/user/1000/xauth_SAasxU --xwayland > > Happy hunting mates! Was the screen locked when you captured the perf output? (In reply to Vlad Zahorodnii from comment #151) > Was the screen locked when you captured the perf output? Screen was not locked. When i dont use suspend to ram or hibernate, kwin_wayland is ok. After first use of suspend or hibernate leeks are happening. perf output was generated after waking up from hibernate and replug external monitor with thunderbolt (to release ram). While the perf test was being generated, I was not doing anything on the computer and screen was NOT locked. I am running mostly: PyCharm, VLC, Brave, FF, Discord with streaming I can retry tests in other conditions, let me know. As an update, we got a response from NVidia, they have a driver fix for this in a future driver update. Don't know which update exactly did that, but I'm not running into this issue anymore. (In reply to Zamundaaa from comment #153) > As an update, we got a response from NVidia, they have a driver fix for this > in a future driver update. Was this discussion public? Can you share the link of this response? Sure, it's all in the #kwin matrix room. (In reply to Zamundaaa from comment #156) > Sure, it's all in the #kwin matrix room. https://i.imgur.com/1msvYCF.png Yeah, we actually can't see it. So, everyone here is in the dark with a device that memory leaks if you unplug/plug again the external monitor. (In reply to Zamundaaa from comment #156) > Sure, it's all in the #kwin matrix room. https://i.imgur.com/1msvYCF.png Yeah, we actually can't see it. So, everyone here is in the dark with a device that memory leaks if you unplug/plug again the external monitor. I was able to ask for NVidia reponse at #kwin:kde.org matrix channel, here's what we got:
> regarding that kwin_wayland leak you pinged about, we have a fix that should be coming in (I think) the next 570 release. I don't know the exact date when that will drop but will try to ping here again when it does
Created attachment 181552 [details]
perf report from kwin_wayland 6.3.90 nvidia-open 575.51.02
I tried kwin 6.3.90 and nvidia-open 575.51.02 (installed with makepkg) on arch linux with kernel 6.14.7. With no luck, the memory leak is still there.
I produced this perf.data in the following steps:
1. meta+L to lock the screen
2. wait for 20s to let the screen turn off.
3. wait for another 20s
4. wake up the screen, login (again)
5. do something for one minute, I observe that the memory used by kwin_wayland goes up for about 6MB/s
6. I run `sudo perf record -F 1000 -p $(pidof kwin_wayland) -g -- sleep 6` and then `sudo perf report`
It seems that nvidia driver 570.153.02 has fixed this problem! I didn't experience any memory leaks after updating to the newly released nvidia driver. (In reply to kde.2ip0k from comment #161) > It seems that nvidia driver 570.153.02 has fixed this problem! I didn't > experience any memory leaks after updating to the newly released nvidia > driver. This is great news. Is anyone else still seeing a memory problem with the 570.153.02 driver? Note that version 575 is a beta version. https://www.nvidia.com/en-us/drivers/unix/ (In reply to kde.2ip0k from comment #161) > It seems that nvidia driver 570.153.02 has fixed this problem! I didn't > experience any memory leaks after updating to the newly released nvidia > driver. Can confirm that with 570.153.02 there is no memory leak for now. I can happily use my second monitor once again ^_^ OS: Gentoo Linux x86_64 Host: 82JW (Legion 5 15ACH6) Kernel: Linux 6.14.5-gentoo I'm on latest KDE build from sources (6.4.80). (In reply to kde.2ip0k from comment #161) > It seems that nvidia driver 570.153.02 has fixed this problem! I didn't > experience any memory leaks after updating to the newly released nvidia > driver. When using this driver, I get GSP timeouts popping up in my journal every time the monitors dim for powersaving, and once it crashed my computer completely. Created attachment 181646 [details]
signature.asc
I was on 550.144.03 but upgraded to 570.153.02 yesterday and haven't had
any issues yet. It's looking like a winner!
Great! (In reply to Evert Vorster from comment #164) > (In reply to kde.2ip0k from comment #161) > > It seems that nvidia driver 570.153.02 has fixed this problem! I didn't > > experience any memory leaks after updating to the newly released nvidia > > driver. > > When using this driver, I get GSP timeouts popping up in my journal every > time the monitors dim for powersaving, and once it crashed my computer > completely. I forgot to mention that I use the proprietary driver with GSP Firmware disabled due to the Wayland frame rate issue. I assume you haven't disabled GSP and/or are using the open kernel module. Since this bug is marked as resolved here, I'd suggest reporting the issue on their GitHub page if it persists - that way it could get more attention from other users and developers. (In reply to kde.2ip0k from comment #167) > (In reply to Evert Vorster from comment #164) > > (In reply to kde.2ip0k from comment #161) > > > It seems that nvidia driver 570.153.02 has fixed this problem! I didn't > > > experience any memory leaks after updating to the newly released nvidia > > > driver. > > > > When using this driver, I get GSP timeouts popping up in my journal every > > time the monitors dim for powersaving, and once it crashed my computer > > completely. > > I forgot to mention that I use the proprietary driver with GSP Firmware > disabled due to the Wayland frame rate issue. I assume you haven't disabled > GSP and/or are using the open kernel module. Since this bug is marked as > resolved here, I'd suggest reporting the issue on their GitHub page if it > persists - that way it could get more attention from other users and > developers. I have reported it on nVidia's forums, thanks very much for the pointer I can confirm that I have been running Nvidia drivers 570.153.02 on Fedora 42 for a few days without any leaks. Thank you! There are other issues, like seldom flickering of one of the screens that can be solved only with kwin_wayland --replace, corruption in LibreOffice and corruption and frequent crashes in Firefox with gfx.webrenderer.all=True (without it, FF frequently uses a lot of CPU). But that's for other bug reports. I can confirm that I have been running Nvidia drivers 570.153.02 on Ubuntu 25.04 without any leaks. Im using hibernation to disc excessively. Thank you! |
