Bug 231628 - KIdleTime/PowerDevil/rsibreak makes Xorg use 100% CPU when computer is idle
Summary: KIdleTime/PowerDevil/rsibreak makes Xorg use 100% CPU when computer is idle
Status: RESOLVED UPSTREAM
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.4
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Will Stephenson
URL:
Keywords:
: 230782 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-22 10:15 UTC by jappel
Modified: 2010-04-27 14:31 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jappel 2010-03-22 10:15:11 UTC
Version:            (using KDE 4.4.1)
OS:                Linux
Installed from:    openSUSE RPMs

After ~ 10 minutes idling suddenly xorg's CPU consumption shoots up to 100%. The effect is reproduceable every time.

It also occurs after some minutes when I switch to a text console (via Ctrl+Alt+F1) and kde is running in the background on another console.

Killing kded4 from the text console brings the xorg's cpu level down. 

Stopping all loaded modules that are listed by
qdbus org.kde.kded /kded loadedModules
via
qdbus org.kde.kded /kded unloadModule xx
is not sufficient to stop the CPU problem.

Please telle me how I can help to debug this further.

Please consider this problem to be more than a cosmetical nuisance, since it affects especially laptop users: The battery charge is wasted and on due to the generally higher temperature (especially on fanless laptops) its life time is shortened. :(
Comment 1 jappel 2010-03-28 19:15:52 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.
Comment 2 Daniel Faust 2010-04-03 11:17:20 UTC
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.
Comment 3 Will Stephenson 2010-04-08 14:22:14 UTC
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
Comment 4 Daniel Faust 2010-04-08 14:51:22 UTC
DPMS (Energy Star):
  Standby: 1200    Suspend: 1800    Off: 2400
  DPMS is Enabled
  Monitor is On
Comment 5 Will Stephenson 2010-04-09 11:45:02 UTC
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
Comment 6 Pit 2010-04-14 11:47:30 UTC
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.
Comment 7 Will Stephenson 2010-04-21 16:41:48 UTC
*** Bug 230782 has been marked as a duplicate of this bug. ***
Comment 8 Will Stephenson 2010-04-21 16:44:59 UTC
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.
Comment 9 Holger Macht 2010-04-21 20:32:57 UTC
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.
Comment 10 Will Stephenson 2010-04-21 22:13:23 UTC
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.
Comment 11 Holger Macht 2010-04-21 23:07:58 UTC
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.
Comment 12 Holger Macht 2010-04-21 23:26:48 UTC
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?
Comment 13 Dario Freddi 2010-04-24 14:24:11 UTC
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
Comment 14 Dario Freddi 2010-04-24 14:25:50 UTC
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
Comment 15 Will Stephenson 2010-04-27 14:31:21 UTC
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).