Created attachment 168172 [details] qdbus-qt5 org.kde.KWin /KWin supportInformation SUMMARY High cpu usage of kscreenlocker_greet and plasmashell processes after switching users. Originally reported via https://bugs.kde.org/show_bug.cgi?id=347772#c75, created a new issue as requested by Nate in https://bugs.kde.org/show_bug.cgi?id=347772#c77. Reproducible: Always. Started to happen after replacing the old AMD video card with the NVIDIA video card. Steps to reproduce: 1. Login as user1 2. Switch user to user2 3. Observe kscreenlocker_greet and plasmashell processes running as user1 begin to consume 100% CPU. 4. Log off user2 and log back in as user1. 5. High CPU usage disappears. The workaround from https://bugs.kde.org/show_bug.cgi?id=347772#c22 does not help. Output of "qdbus-qt5 org.kde.KWin /KWin supportInformation" is attached. SOFTWARE/OS VERSIONS Operating System: openSUSE Leap 15.5 KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 Kernel Version: 5.14.21-150500.55.52-default (64-bit) Graphics Platform: X11 Graphics Processor: NVIDIA GeForce RTX 4060 Ti/PCIe/SSE2 Nvidia drivers: nvidia-video-G06-550.67-lp155.20.1.x86_64)
Output of the following is attached. perf record -p $(pidof plasmashell) -e cpu-cycles --call-graph fp perf report > perf.report
Created attachment 168173 [details] perf report for the plasmashell process with high CPU usage
*** Bug 486788 has been marked as a duplicate of this bug. ***
Thank you for the bug report! I'm so sorry we weren't able to get to it yet, especially given the debugging you've already done. However I can't reproduce this on my system running git master. Can you check and see if it's still an issue in Plasma 6.3.5 or later? Thanks a lot!
Still an issue on: Operating System: openSUSE Leap 15.6 KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 Kernel Version: 6.4.0-150600.23.47-default (64-bit) Graphics Platform: X11 Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 125.7 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 4060 Ti Manufacturer: ASUS Outputs of "qdbus-qt5 org.kde.KWin /KWin supportInformation" and "qdbus6 org.kde.KWin /KWin supportInformation" are attached.
Created attachment 181131 [details] qdbus-qt5 org.kde.KWin /KWin supportInformation
Created attachment 181132 [details] qdbus6 org.kde.KWin /KWin supportInformation
Had similar issues. Changed from sddm to gdm and problem lessened. Changed video card with more vram have not had an issue since. I did read an article about sddm not working well with Wayland and I had used gdm before. Can now have at least three sessions running with no issues. Check amount of vram that is being used. I am finding that over 1Gig of Vram is required for each session. Looking at a remote machine that is in power saving mode, vram is about 1.6Gig for a single session. Kscreenlocker is using 286MiB of that session.
(In reply to Robin Laing from comment #8) > Had similar issues. Changed from sddm to gdm and problem lessened. Changed > video card with more vram have not had an issue since. I did read an > article about sddm not working well with Wayland and I had used gdm before. > > Can now have at least three sessions running with no issues. > > Check amount of vram that is being used. I am finding that over 1Gig of > Vram is required for each session. Looking at a remote machine that is in > power saving mode, vram is about 1.6Gig for a single session. Kscreenlocker > is using 286MiB of that session. I'd expect 16gb of vram on my 4060 ti should have been sufficient ...
I can't reproduce it either. I'm using sddm with wayland as well. Operating System: Arch Linux KDE Plasma Version: 6.6.2 KDE Frameworks Version: 6.23.0 Qt Version: 6.10.2 Kernel Version: 6.19.6-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics Memory: 32 GiB of RAM (31.1 GiB usable) Graphics Processor: NVIDIA GeForce RTX 4060 Manufacturer: ASUS
Vadym, are you able to reproduce this issue on Wayland too? Or only on X11?
(In reply to Nate Graham from comment #11) > Vadym, are you able to reproduce this issue on Wayland too? Or only on X11? To be honest, the lack of progress on this issue (since comment 7) forced me to switch my workflow and stop using this feature. I will soon be upgrading to openSUSE 16.0, will test after upgrade.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
(In reply to Vadym Krevs from comment #12) > (In reply to Nate Graham from comment #11) > > Vadym, are you able to reproduce this issue on Wayland too? Or only on X11? > > To be honest, the lack of progress on this issue (since comment 7) forced me > to switch my workflow and stop using this feature. I will soon be upgrading > to openSUSE 16.0, will test after upgrade. https://bugs.kde.org/show_bug.cgi?id=485067 (In reply to Vadym Krevs from comment #12) > (In reply to Nate Graham from comment #11) > > Vadym, are you able to reproduce this issue on Wayland too? Or only on X11? > > To be honest, the lack of progress on this issue (since comment 7) forced me > to switch my workflow and stop using this feature. I will soon be upgrading > to openSUSE 16.0, will test after upgrade. Well, I've tried. I've updated my openSUSE Leap 15.6 system to Leap 16.0 on Sunday and everything is working using X11. Today I've attempted to login using Plasma/Wayland session from SDDM in order to reproduce this defect. Sadly, the screen goes black and that's it. I ssh'd into the desktop from another laptop before attempting this and ran top and observed kwin_wayland process initially spiking up to consume ~2000% CPU (my desktop has a 16 core/32-thread processor hence the percentages) and then settle on constant 30-40% CPU usage. It seems that there was an attempt to restore the Plasma session - System Monitor was also running and constantly consuming 30-40% CPU. I waited for a couple of minutes - thinking maybe some Mesa caches need regenerating, etc - but nothing changed, the screen stayed black and these two processes (as well as some others) were constantly spinning at 30-40% CPU. I guess I have some "fun" to look forward to when Plasma drops support for X11 ... Rebooted and tried again - same results. Switched to runlevel 3 and then back to 5 and attempted to login into Plasma/X11 session from SDDM and attempted to reproduce the issue as described in comment #1. Sadly, the issue still happens exactly as described there. This is my current hardware/software setup: Operating System: openSUSE Leap 16.0 KDE Plasma Version: 6.6.3 KDE Frameworks Version: 6.24.0 Qt Version: 6.11.0 Kernel Version: 6.12.0-160000.27-default (64-bit) Graphics Platform: X11 Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 128 GiB of RAM (125.7 GiB usable) Graphics Processor 1: NVIDIA GeForce RTX 4060 Ti/PCIe/SSE2 Manufacturer: ASUS Nvidia drivers: nvidia-driver-G06-kmp-default-580.142_k6.12.0_160000.27-lp160.46.3.x86_64 $ inxi -aG Graphics: Device-1: NVIDIA AD106 [GeForce RTX 4060 Ti 16GB] vendor: Micro-Star MSI driver: nvidia v: 580.142 alternate: nouveau,nvidia_drm non-free: 550.xx+ status: current (as of 2024-09) arch: Lovelace code: AD1xx process: TSMC n4 (5nm) built: 2022+ pcie: gen: 2 speed: 5 GT/s lanes: 8 link-max: gen: 4 speed: 16 GT/s ports: active: none off: DP-1 empty: DP-2,DP-3,HDMI-A-1 bus-ID: 08:00.0 chip-ID: 10de:2805 class-ID: 0300 Device-2: Logitech Logitech Webcam C925e driver: snd-usb-audio,uvcvideo type: USB rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 3-2:3 chip-ID: 046d:085b class-ID: 0102 serial: 9F4B7C5F Display: x11 server: X.Org v: 21.1.15 with: Xwayland v: 24.1.6 compositor: kwin_x11 driver: X: loaded: nvidia unloaded: modesetting,vesa alternate: fbdev,nouveau,nv gpu: nvidia,nvidia-nvswitch display-ID: :0 screens: 1 Screen-1: 0 s-res: 3840x2160 s-dpi: 120 s-size: 813x457mm (32.01x17.99") s-diag: 933mm (36.72") Monitor-1: DP-0 res: 3840x2160 hz: 60 dpi: 140 size: 698x393mm (27.48x15.47") diag: 801mm (31.54") modes: N/A API: OpenGL v: 4.6.0 vendor: nvidia v: 580.142 glx-v: 1.4 direct-render: yes renderer: NVIDIA GeForce RTX 4060 Ti/PCIe/SSE2 memory: 15.62 GiB API: Vulkan v: 1.4.309 layers: 3 device: 0 type: discrete-gpu name: NVIDIA GeForce RTX 4060 Ti driver: N/A device-ID: 10de:2805 surfaces: xcb,xlib API: EGL Message: EGL data requires eglinfo. Check --recommends.
Created attachment 191332 [details] qdbus6 org.kde.KWin /KWin supportInformation from my current Leap 16.0 system
Attached output of "qdbus6 org.kde.KWin /KWin supportInformation" from my current Leap 16.0 system.
I've resolved the black screen issue when trying to login into a Plasma Wayland session reported in comment #14 and attempted to reproduce the original issue. The good news is that the issue is non-existent under Wayland. The bad news is that the same weird differences between X11 and Wayland sessions as reported in https://bugs.kde.org/show_bug.cgi?id=502626#c7 are still there. Session restore is borked - half of the apps listed in https://bugs.kde.org/show_bug.cgi?id=518629 do not restore on login into a Wayland session.
So, wouldn't it be better for you to close this issue and reopen the other ones?
(In reply to Marcelo Lacerda from comment #18) > So, wouldn't it be better for you to close this issue and reopen the other > ones? My issue is on x11 and still not fixed. And I have no time to troubleshoot new issues arising from the switch to wayland.
(In reply to Vadym Krevs from comment #19) > My issue is on x11 and still not fixed. And I have no time to troubleshoot > new issues arising from the switch to wayland. Fair enough. I understand you're still seeing kscreenlocker_greet and plasmashell processes use a lot of CPU after switching users. This report is only for that issue, let's keep the conversation focused on that. The more focused the conversation, the easier it is for the developers to understand the report and fix the bug.