Summary: | KIdleTime/PowerDevil/rsibreak makes Xorg use 100% CPU when computer is idle | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kdelibs | Reporter: | jappel |
Component: | general | Assignee: | Will Stephenson <wstephenson> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | hessijames, holger, kamikazow, P.Suetterlin, wstephenson |
Priority: | NOR | ||
Version: | 4.4 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
jappel
2010-03-22 10:15:11 UTC
Additional Information: The CPU consuption goes down to normal level as soon as the mouse is moved while the according X-Display is active. Stopping all modules with for f in `qdbus org.kde.kded /kded loadedModules`; do echo Stopping $f; qdbus org.kde.kded /kded unloadModule $f; done does not help. Even stopping kded4 with kill -19 pid does nothing whereas killing it with kill -9 pid does. exactly the same problem here. the problem occures since a kde update to 4.4 rc? and still exists with kde 4.4.2. i'm using opensuse 11.2 with nvidia drivers 190.53 and the problem also exists with any new user created and only the default kde apps running. i'm trying to debug this for months but without any luck. this is a really grave bug so any help would be great. I'm suffering from this too and I have decided today is the day when I stop hearing that high pitched 100% fan whine from my thinkpad when I'm not using it. Can other reporters tell me if DPMS is enabled while Xorg is at 100% cpu? xset -q will tell you DPMS settings eg: DPMS (Energy Star): Standby: 1200 Suspend: 1800 Off: 0 DPMS is Enabled Monitor is On DPMS (Energy Star): Standby: 1200 Suspend: 1800 Off: 2400 DPMS is Enabled Monitor is On It looks a lot like a bug in the openSUSE X server packages. If this is confirmed I will close this bug as downstream. How kded4 triggers it is not clear. https://bugzilla.novell.com/show_bug.cgi?id=584919 I also have this problem. However, for me it is not when I boot the system and log in - then everything is fine. It only shows up after an suspend-to-ram. *** Bug 230782 has been marked as a duplicate of this bug. *** The bug is in the X SYNC extension which is heavily used by PowerDevil (and rsibreak). An alarm set by KIdleTime's SYNC backend is not cleared after a suspend (or other cases, not entirely clear here) and then fires repeatedly on the next idle. I will check the SYNC backend to make sure it is not doing anything wrong or odd to trigger the Xorg bug. Will, this can be reproduced with the small code snipped from http://mail.gnome.org/archives/gtk-devel-list/2007-July/msg00017.html And that's basically the code KIdleTime uses. Holger, do you know a more precise way to reproduce the bug apart from "run code that uses SYNC alarms and suspend and resume"? Egbert is preparing a patch for Xorg at https://bugzilla.novell.com/show_bug.cgi?id=584919 and atm he is relying on me to test it works. No, I have no better way of testing it, sorry. But good to see that a fix is/will be available. I will test it and report back. AFAICT, now I only get the event once and it never fires again afterwards. I'm pretty sure that it did before installing the new xorg server. Can you confirm that? SVN commit 1118329 by dafre: CCBUG: 231628 Be sure to stop catching resume events when requested. This might be also related to the bug in CC. P.S. for the bug in question: I also fixed (and backported) some more stuff before this one. Please test again and report. M +1 -1 kidletime.cpp M +4 -2 xsyncbasedpoller.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1118329 SVN commit 1118330 by dafre: CCBUG: 231628 Backporting r1118329: Be sure to stop catching resume events when requested. M +1 -1 kidletime.cpp M +4 -2 xsyncbasedpoller.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1118330 Fixed in Xorg. From https://bugzilla.novell.com/show_bug.cgi?id=584919: - Prevent XSync Alarms from senselessly calling CheckTrigger() when inactive. If an XSync Alarm is set to inactive there is no need to check if a trigger needs to fire. Doing so if the counter is the IdleCounter will put the server on 100 percent CPU load since the select timeout is set to 0 (bnc #584919). |