kwin uses ~100% CPU when I switch to a text console (e.g. CTRL+ALT+F3). Peculiar things I've observed: *) kwin's CPU usage goes back to normal when I switch back to X (CTRL+ALT+F7) and reproducibly goes again to 100% when I switch to text console. *) It only happens after I've started e.g. firefox or thunderbird, but not after only having started e.g. libreoffice (with libreoffice-kde installed) or konsole. *) When I close firefox (or thunderbird) again and switch to text console, kwin still jumps up to 100%, i.e. having started one of those applications 'spoils' kwin's behavior on the text console. *) When I do a kwin --replace & with a 'spoiled' kwin running, its behavior upon switching is OK again, regardless of whether firefox is still running. Then I start thunderbird, switch back and forth between firefox, thunderbird, firefox – then kwin is spoiled again. Reproducible: Always Steps to Reproduce: 1. Start a clean session 2. Start firefox 3. Switch to a text console (e.g. CTRL+ALT+F3) Actual Results: kwin's CPU usage in text console is ~100% Expected Results: kwin's CPU usage should stay low (~3 % in my case) in both, text and X mode. Versions: kwin 4.12.2 xorg 7.6 Firefox 27.0 (no hardware acceleration enabled) Thunderbird 24.3.0 openSUSE 13.1 kwin output upon kwin --replace: OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GT 525M/PCIe/SSE2 OpenGL version string: 4.4.0 NVIDIA 331.38 OpenGL shading language version string: 4.40 NVIDIA via Cg compiler Driver: NVIDIA Driver version: 331.38 GPU class: GF100 OpenGL version: 4.4 GLSL version: 4.40 X server version: 1.14.3 Linux kernel version: 3.11.10 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no
please provide the output of qdbus org.kde.kwin /KWin supportInformation and check whether dmesg | grep NVRM says sth. like "NVRM: Your system is not currently configured to drive a VGA console" ? Mozilla/XUL requirement sounds like a track, though.
Created attachment 85082 [details] output of qdbus org.kde.kwin /KWin supportInformation I attached the output of qdbus org.kde.kwin /KWin supportInformation. dmesg | grep NVRM indeed says: [ 15.047826] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 331.38 Wed Jan 8 19:32:30 PST 2014 [ 33.418898] NVRM: Your system is not currently configured to drive a VGA console [ 33.418903] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver [ 33.418905] NVRM: requires the use of a text-mode VGA console. Use of other console [ 33.418907] NVRM: drivers including, but not limited to, vesafb, may result in [ 33.418909] NVRM: corruption and stability problems, and is not supported. What can I do about that?
https://wiki.archlinux.org/index.php/GRUB#Disable_framebuffer But I don't know whether SuSE uses GRUB2 resp. /etc/defaults/grub - there might be some yast layer inbetween. In grub1, do NOT use vga=791 etc., but rather "vga=normal" as kernel parameter. nouveau should be blacklisted, resp. at least modesetting prevented in the grub kernel line (nomodeset)
I added GRUB_TERMINAL_OUTPUT=console to /etc/default/grub and rebooted, but it didn't seem to make a difference, neither to the dmesg |grep NVRM output nor to kwin's behavior. On the grub2 command line I tried: set gfxpayload=1600x900 which gave me tiny fonts/resolution on the tty (as opposed to the coarse tty resolution which is default on my system) but it didn't change kwin's behavior described above. I suppose you cannot reproduce the behavior I described…? Do you have an nvidia card?
(In reply to comment #4) > I added GRUB_TERMINAL_OUTPUT=console to /etc/default/grub and rebooted did you "grub-mkconfig -o /boot/grub/grub.cfg" ? > set gfxpayload=1600x900 > which gave me tiny fonts/resolution on the tty yes, a high resolution Framebuffer Console - you want set gfxpayload=text > it didn't change kwins behavior described above. would not be expectable - on the contrary. > I suppose you cannot reproduce the behavior I described…? Nope. Any particular site i should browse to? (No flash installation, btw.) > Do you have an nvidia card? GT 520
(In reply to comment #5) > > I added GRUB_TERMINAL_OUTPUT=console to /etc/default/grub and rebooted > did you "grub-mkconfig -o /boot/grub/grub.cfg" ? I had not done that. But now I manually edited /boot/grub2/grub.cfg and changed terminal_output gfxterm to terminal_output consoloe Now dmesg | grep NVRM only shows: [ 14.086256] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 331.38 Wed Jan 8 19:32:30 PST 2014 But it didn't change kwin's described behavior. > > I suppose you cannot reproduce the behavior I described…? > Nope. > Any particular site i should browse to? (No flash installation, btw.) None of that. Just having started firefox is sufficient to trigger the high CPU load on my system. > > Do you have an nvidia card? > GT 520 Shouldn't be THAT different to GT 525M, should it? Are you using the nouveau or the proprietary driver? I cannot reproduce it on my desktop system (the one that it occurs on is a laptop) using some Geforce 9xxx card, all software versions the same (openSUSE 13.1, nvidia 331.38, kernel 3.11.10, kde 4.12.2, firefox 27.0). That other system shows the 'Your system is not currently configured to drive a VGA console' message, so that doesn't seem to be related.
(In reply to comment #6) > Now dmesg | grep NVRM only shows: > [ 14.086256] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 331.38 Wed > Jan 8 19:32:30 PST 2014 > > But it didn't change kwin's described behavior. Just had to rule out this (since it's a common cause for all kinds of issues in that regard) > Shouldn't be THAT different to GT 525M, should it? Are you using the nouveau > or the proprietary driver? Blob. GF108 ./. GF119, seems basically the same chip, though. *** But it's a 32bit installation! > I cannot reproduce it on my desktop system I assume it's x64 as well? Could be due to powermizer? ("nvidia-settings", GT 520 is a desktop GPU as well) > (openSUSE 13.1, nvidia 331.38, kernel 3.11.10, kde 4.12.2, firefox 27.0). arch, nvidia 331.38, linux 3.12.9, firefox 27.0. kwin is 4.11 branch + some 30 local patches (you're on kwin 4.11.6 - kde-workspace has no 4.12) Does it behave the same with XRender/No compositing?
I can confirm this as well on KDE 4.13.0. However, for me, it doesn't seem to be related to Firefox. In a fresh session, switching to a different vt causes 100% CPU usage from kwin, and that fresh session only has Konqueror, Kmail and lots of Konsoles running. I paused compositing (with Alt+Shift+F12) and switched to the text console on vt1 and observed <1% kwin CPU usage. Unpausing compositing and switching to vt1 again still reveals <1% kwin CPU usage. At this point, I tried starting Firefox to "taint" the running kwin process, but to no effect. So, it appears that doing a pause/unpause of compositing masks this issue, at least for the current session. I do also have an Nvidia card (GTX 670), but I do not have the VGA console issue: $ dmesg | grep NVRM [ 12.234272] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 337.12 Fri Apr 4 14:51:15 PDT 2014 Gentoo, Nvidia 337.12, Linux 3.14.1, Firefox 28.0, KDE 4.13.0 I will attach the output of `qdbus org.kde.kwin /KWin supportInformation` in a moment.
Created attachment 86175 [details] Output of qdbus org.kde.kwin /KWin supportInformation
can you try to $ export __GL_YIELD="USLEEP" $ kwin --replace & and check the result reg. CPU usage on VT1?
Even with __GL_YIELD="USLEEP", I still see 100% CPU usage while on vt1.
(In reply to comment #8) > So, it appears that doing a pause/unpause of compositing masks this issue, at > least for the current session. Let's do a wild guess. login to KDE, wait a short while (we need 500 repaints), then run $ qdbus org.kde.kwin /KWin supportInformation | grep block and ensure the problem is present on VT1 what does it say and what's in adition the output of $ grep -i triple /var/log/Xorg.0.log
Ok, in this 10 minute old KDE session: $ qdbus org.kde.kwin /KWin supportInformation | grep block Painting blocks for vertical retrace: yes $ $ grep -i triple /var/log/Xorg.*.log $ High kwin CPU usage is still observed while on vt1.
Semi-dead end :-( The idea was that pot. you're triple buffering, we misdetect that and flood the scanout buffer. However (plan B ;-) You could try whether this also happens if you enable triple buffering (no blocking buffer swap -> no wait -> no option for a busy wait) /etc/X11/xorg.conf.d/20-nvidia.conf Section "Device" Identifier "Default nvidia Device" Driver "nvidia" Option "NoLogo" "True" # no advertising spam Option "CoolBits" "1" # evtl. more perf. control Option "TripleBuffer" "True" # <---------- this is the relevant line EndSection
Now you're on to something! I enabled TripleBuffer, and no more high CPU usage from kwin while on vt1.
I had exactly the same issue, and workaround with setting Option "TripleBuffer" "True" solved it as well. I noticed high CPU usage not only when switching to vt1, but also when the screen was locked (with a simple locker). The workaround above solves that problem as well (at least in my current test).
I can confirm this on Fedora 21 and for AMD/ATI graphics $ rpm -q kwin kwin-4.11.14-3.fc21.x86_64 $ lspci | grep VGA 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R4/R5 Graphics]
Created attachment 90134 [details] Output of qdbus org.kde.kwin /KWin supportInformation
> Painting blocks for vertical retrace: yes See comment #14, but I don't know whether the radeon/gallim driver interprets that option. The only thing I could suggest was to (forcefully) disable vsync in KWin settings as well as https://wiki.archlinux.org/index.php/ATI#Turn_vsync_off Dev note: we'd have to check the fg terminal and compare it to our X11 terminal, but this may require root permissions, is hardly portable - and polling sucks. In general, this is therefore probably sth. the driver should reasonably handle
Just added myself to the CC list as I have this issue too; KDE 4.13.3 on AMD Phenom X4 965 with nVidia GeForce GTX 460 running 4.4.0 NVIDIA 331.113 driver. As Neil reported above, pausing compositing stops the kwin hogging behaviour on switching to VT1. Since this machine runs 24/7 I can live with that workaround. Let me know if I can supply useful diagnostic information.
See comment #15 This happens because the driver performs a busy wait for the next sync event, which won't happen while on VT1 That's a driver bug - we can't do anything about it (see comment #19 for problems to even somehow workaround it)
*** Bug 344175 has been marked as a duplicate of this bug. ***
I am seeing the same problem since I switched desktop effects on a while ago. KDE 4.12.5, Nvidia 346.35, GT430. The TripleBuffer and USLEEP workarounds did not work for me, but it seems adding GLVSync=false to kwinrc (under [Compositing]) did. Did someone notify Nvidia about this bug in their driver?
(In reply to Thomas Boerkel from comment #23) > it seems adding GLVSync=false to kwinrc (under [Compositing]) did. Certainly not - the key doesn't exist anymore (nor did in your KWin version) You'd want to set "Tearing prevention" to "None" in the 3rd tab of "kcmshell4 kwincompositing" to cause such setting. > Did someone notify Nvidia about this bug in their driver? nvidia is ("of course") aware that they perform busy waits (by default) to sync to the retrace, but I'm not sure whether there're open tickets about (various: this affects vdpau and I currently rather get 100% in Xorg.bin after turning back to X11 - despite TB/USLEEP) issues reg. what happens when the gl/vdpau client is no longer on the foreground terminal (while the consequences of busy waiting forever are quite obvious ;-) nvidia has no open bugtracker :-(
When I go to system settings, desktop effects, it says that desktop effects are disabled because of a kwin crash in the past. When I try to enable OpenGL detection, it says the system for desktop effects is not running. However, I can see desktop effects. For example, windows get transparent and do glow when I drag them.
Please attach the output of qdbus org.kde.KWin /KWin supportInformation
Created attachment 91082 [details] qdbus org.kde.KWin /KWin supportInformation Seems that compositing is not active, but I still get transparent and glowing windows.
Maybe running sth. like compton, xcompmgr or another compositor aside? > Multi-Head: yes This is also a multihead system - there may be two instaces of kwin running (only the first one can be assigned to the vanilla dbus service, the other one will ahve a suffix. Check "qdbus | grep -i kwin") and one has compositing enabled while the other doesn't?
Sorry that I did not mention multihead. Now I rebooted the system. 2nd session not active, yet. System settings/desktop effects is now working normally again. qdbus | grep -i kwin org.kde.KWin org.kde.kwin org.kde.kwin-5343 org.kde.kwin.Compositing org.kde.kwin.Effects org.kde.kwin.Screenshot org.kde.kwin.Scripting org.kde.kwin-5344 org.kde.kwin-screen-1 dbus org.kde.KWin /KWin supportInformation now shows compositing active, too. Attaching output.
Created attachment 91083 [details] qdbus org.kde.KWin /KWin supportInformation
I have now the 2nd session active again and locked. This did almost always trigger 100% CPU in the past on the 1st session. But it does not anymore. If GLVSync=false in kwinrc did not do anything then I don't know why it does not happen at the moment. If it happens again, I'll try the tearing option. This is set to "auto" at the moment.
Created attachment 91084 [details] qdbus org.kde.KWin /KWin supportInformation from James From duplicate Bug 344175.
From duplicate bug https://bugs.kde.org/show_bug.cgi?id=344175 > please attach the output of > qdbus org.kde.KWin /KWin supportInformation Added Attachment. Can someone please explain "Status RESOLVED UPSTREAM"? This bug is over a year old and still not "resolved". > This is (likely) due to vertical sync I set "Tearing Prevention (VSync) None", in "Configure desktop effects", under the "Advanced" tab, with "desktop effects" still active. I no longer see the 100% CPU usage. In case it might be useful to anyone, here is: $ qdbus | grep -i kwin org.kde.internal.KSettingsWidget_kcm_kwin4_effect_builtins org.kde.internal.KSettingsWidget_kcm_kwincompositing org.kde.kwinCompositingDialog org.kde.KWin org.kde.kwin org.kde.kwin-620 org.kde.kwin.Compositing org.kde.kwin.Effects org.kde.kwin.Screenshot org.kde.kwin.Scripting
(In reply to James from comment #33) > Can someone please explain "Status RESOLVED UPSTREAM"? This bug is over a > year old and still not "resolved". That's the bugzilla entry to say "someone elses problem". We cannot fix, nor even workaround (see comment #14) this problem. > I set "Tearing Prevention (VSync) None" [...] I no longer see the 100% CPU usage. As expected. Apparently more drivers perform a busy wait for the retrace signal (which doesn't occur) You could instead also try ----------- ~/.drirc ------------------ <driconf> <device screen="0" driver="dri2"> <option name="fthrottle_mode" value="1" /> </device> </driconf> ------------------------------------- 0: busy wait 1: usleep 2: software IRQs - though 2 apparently at least used to be the default.
(In reply to Thomas Boerkel from comment #29) > Sorry that I did not mention multihead. Now I rebooted the system. 2nd > session not active, yet. System settings/desktop effects is now working > normally again. TripleBuffering seems to be enabled (for confirmation: "grep -i triple /var/log/Xorg.0.log" - others: that's for the nvidia blob only!) but I wonder whether the multihead could make the situation more complex. Do you get full cpu load on a single head setup (and switching that to VT1) as well?
(In reply to Thomas Lübking from comment #35) > TripleBuffering seems to be enabled (for confirmation: "grep -i triple > /var/log/Xorg.0.log" - others: that's for the nvidia blob only!) but I > wonder whether the multihead could make the situation more complex. Do you > get full cpu load on a single head setup (and switching that to VT1) as well? Yes, TripleBuffering is enabled. I had multihead before I enabled desktop effects. When I can reproduce it again, I'll try with single head.
> We cannot fix, nor even workaround (see comment #14) this problem. On my system, I am running radeon, not nvidia. Is this bug something that should be filed with the radeon kernel module people?
Another 2 1/2 years on, I am no longer seeing this problem on my system. On Arch Linux, with: linux 4.13.4-1 kwin 5.10.5-1 running a triple head Radeon 5570, and setting: System Settings -> Display and Monitor -> Compositor -> Tearing prevention ("vsync"): -> Never Starting a clean session, starting Firefox, then switching to a text console, CPU usage is normal. Hopefully, this is no longer an issue for anyone.
For what it's worth: I cannot reproduce this problem with kwin 5.10.95 anymore.