Version: (using Devel) Compiler: gcc 4.1.2 OS: Linux Installed from: Compiled sources Using the kde 4.1.72 snapshot packages from Gentoo's experimental overlay, on an AMD64 dual-core laptop with NVidia graphics. The issue seems to be related to powerdevil. Some time after DPMS timeout turns off the laptop display, the X server itself begins to consume 100% of one CPU. It does not happen immediately after the display shuts off, but somewhere between 5 and 15 minutes after then. After removing powerdevil from the system, the problem has gone away.
Same issue with 4.1.3 and powerdevil 1.4.0. The issue did not exist with powerdevil 1.2.0.
The reason behind this is rather simple: on some hardware configurations (happens here too) DPMS just hog the system when they get changed. In 1.2.0 the issue didn't exist since Powerdevil wasn't using DPMS. This is why I added a checkbox "Let powerdevil manage screen powersaving" in the general tab. By unchecking it, Powerdevil will bypass dynamic DPMS changes, and you will not experience this kind of problems. Unfortunately there is no other solution, since the problem lies at a very lower level
This is still a problem even with that option unchecked. I left `top` running, waited a while and watched as X began to suck up the CPU. After that started, I moved the mouse around a bit and X returned to normal. So there's another problem with powerdevil, or that solution is incomplete.
There is eventually another problem, but I can't reproduce it here. I would appreciate if you could dig a bit deeper into it and give me some more information about it.
I have the same problem. The CPU still goes up after deactivating the mentioned option. One thing chnaged though. With that option on, the screen doesn't blank. So now, with this option off, me screen finally blanks again. :D Anyway. Do you have any hints how to debug the daemon?
Rather easy: run gdb against kded4, you'll debug each kded module this way, powerdevil included.
Ok, here is my yesterday's first approach in debugging this: run in console with --nofork -> screen blanks -> 100% problem occurs but no output run in dbg with "run --nofork" -> screen does not blank -> no 100% problem, no output attach to running kded4 (no idea how to do it right. There was only lib-loading output at first, then silence. I did "gdb kded4 PID" (as described on the techbase page) but didn't know what to do next. Since typing any command later would stop whatever is causing the 100% problem anyway, I'm a bit unsure here.) -> screen blanks -> no 100% problem, no output One thing though. On the configuration page, the drop down box "When System is idle for more than [15 min]: is empty. I mean it stands on an empty item (the other items are selectable though). The cpu goes up after 15 minutes. Could a non-specified value here cause such a problem?
Created attachment 28588 [details] powerdevilrc
Created attachment 28589 [details] powerdevilprofilesrc
Happens here as well. It happens before the 6 minute time to turn off the monitor is reached. At about 3 minutes or so. Moving the mouse fixes it as described above. Also the monitor doesn't turn itself off (laptop LCD). This happened already with 1.2.0, don't know if it's related at all. I have set it to turn off but it just stays on. Sometimes it works, most of the time it doesn't.
For anyone triggering this problem, it could be useful running kded4 from command line and pasting the output (possibly only PowerDevil's one) here
I'll paste the output then. It only outputs this when it's started though. Nothing is outputted when it's running. Also, when I measured the time from the last mouse movement and the 100% cpu usage starting, it was almost exactly 120 seconds. cbr@shield:~$ kded4 kded(17783) KdedGlobalAccel::loadSettings: Shortcut found twice in kglobalshortcutsrc. kded(17783) KdedGlobalAccel::loadSettings: Shortcut found twice in kglobalshortcutsrc. kded(17783) KdedGlobalAccel::loadSettings: Shortcut found twice in kglobalshortcutsrc. kded(17783) KdedGlobalAccel::loadSettings: Shortcut found twice in kglobalshortcutsrc. kded(17783) Solid::Control::ManagerBasePrivate::loadBackend: Error loading ' "Liba-võrk" ', KService said: "QLibrary::resolve_sys: Symbol "init_solid_fakenet"undefined in /usr/lib/kde4/solid_fakenet.so (/usr/lib/kde4/solid_fakenet.so: undefined symbol: init_solid_fakenet)" kded(17783) Solid::Control::ManagerBasePrivate::loadBackend: Backend loaded: "Võrguhaldur 0.7" kded(17783) Solid::Control::ManagerBasePrivate::loadBackend: Backend loaded: "HAL-Power" kded(17783) XSyncBasedPoller::XSyncBasedPoller: XSync Inited kded(17783) XSyncBasedPoller::XSyncBasedPoller: XSync Inited kded(17783) PowerDevilDaemon::profileFirstLoad: Profile initialization kded(17783) PowerDevilDaemon::poll: Polling started, idle time is 0 seconds kded(17783) PowerDevilDaemon::poll: Minimum time is 120 seconds kded(17783) PowerDevilDaemon::poll: Nothing to do, next event in 120 seconds kded(17783) PowerDevilDaemon::poll: Polling started, idle time is 0 seconds kded(17783) PowerDevilDaemon::poll: Minimum time is 120 seconds kded(17783) PowerDevilDaemon::poll: Nothing to do, next event in 120 seconds cbr@shield:~$
Same problem for me. OS: Gentoo AMD64 multilib Nvidia Graphics with NVIDIA Driver X.Org X Server 1.5.2 KDE 4.1.3 Powerdevil 1.4.1
Same here: after 60 seconds of idle time, X takes 50% cpu until I move the mouse again. Unchecking "Let powerdevil manage screen powersaving" doesn't help. Only option is to remove powerdevil. I'm running KDE trunk, revision 889957. I'm also on Gentoo amd64. xf86-video-ati xorg-server 1.5.3
Quoting me from comment #7: > One thing though. On the configuration page, the drop down box "When System is > idle for more than [15 min]: is empty. I mean it stands on an empty item (the > other items are selectable though). The cpu goes up after 15 minutes. Could a > non-specified value here cause such a problem? For me the problem was solved after choosing "Do Nothing" there. Could you please check if these drop down boxes stand on any value? Not that you have to change the right one for the mode you are running in. I have no idea if that is relevant but as I said, it solved the problem for me (or rather, the problem was solved at the same time :)).
(In reply to comment #15) > > For me the problem was solved after choosing "Do Nothing" there. It didn't help here.
I checked with 2 systems now: - Intel with Gentoo 32 Bit and Nvidia Graphics + Nvidia Driver - AMD64 with Gentoo 64 Bit and Nvidia Graphics + Nvidia Driver On both I had to disable any screen related setting in "Edit Profiles": unchecked "Disable KWin...." unchecked "Dim display...." Set "When system is idle..." to "Do Nothing" Now it seems to be "quiet". At least on the 32 Bit machine I can surely confirm. On the 64 Bit I need to test more thoroughly.
ok, so that sounds like a workaround. However, it disables some of most useful functionality of Powerdevil, and really needs to be fixed. I think releasing 4.2 with Powerdevil in the state it's in now would be really problematic for laptop users.
Settings as suggested in comment 17 seem to have no effect on this issue for me.
"In the state it is" is a generic word, such as the description of this problem has been. I already told you I can't reproduce this problem, and it really affects a small percentage of the users, so I need more informations, I'll ask again: Useful things you can do: - Start KDED4 from console and paste here the output *when the problem happens*, having the startup output doesn't really help. kded4 will keep spitting out stuff, and if PowerDevil is the cause of X hogging, it will spit out a lot of stuff when this issue happens. - Attach KDED4 to GDB and see what the problem is, though if you are not familiar with GDB, I strongly suggest you to gear towards the solution I suggested earlier. Thanks
Thus far, I've been able to yield no useful information with either approach. Running kded4 against gdb shows that kded4 remains idle (within a select() call) at the time of the issue, thus no output is generated on the console at that time and no action is being taken by kded4 itself. This is why it seems that there's something powerdevil may be performing during kded4 startup that will trigger a runaway X after a certain timeout. Needless to say, debugging X to find out what is happening at the point it goes runaway would be a difficult task. Personally, I'm just a user of powerdevil and am completely unfamiliar with how it functions, so it's rather difficult to track what it does at startup. If I can't figure out what the problem is myself, I'm more than happy to give you all the information I can to help you reproduce it in your environment.
Like I commented above, it doesn't "spit out" anything when the problem starts into the terminal. It just outputs the start-up stuff.
Be happy: when I was almost losing hope, I finally managed to reproduce it. So screw anything I've said before: all I need now is to know your X Server version (one should look like 7.x and the other 1.x). Please answer this question as it might be very relevant
$ X -version X.Org X Server 1.5.3
xorg-server 1.4.2, xorg-x11 7.3
Xorg 7.4 and XServer 1.5.3.
amd64, Xorg 7.4 and XServer 1.5.3.
I can confirm this also. As already reported I was able to side-step the problem by disabling all idle actions in Power Management setup. Running xorg 7.4, xserver-xorg-core 1.5.2, amd64, Kubuntu 8.10.
xorg-server 1.5.2 (of Xorg X11 7.4)
*** Bug 176932 has been marked as a duplicate of this bug. ***
Thank you guys, this is enough. You will have some news soon.
Rejoice people, I have finally fixed this bastard in my local copy, it was an hard round. Thanks everyone for your prompt answers and your reports, I will commit into trunk and release a backport in the next hours, just hold it for some more time (just the time to escape my proxied connection in university)
SVN commit 892951 by dafre: BUG: 174897 So that's it. It probably was a strange behavior caused by checking for XSync extension more than once, even though I'm still convinced there is something wrong in X, since this behavior is way too strange... Anyway, fixed now, making also the poller a singleton, so that we are sure initialization takes place only once. M +5 -4 PollSystemLoader.cpp M +61 -32 XSyncBasedPoller.cpp M +6 -1 XSyncBasedPoller.h WebSVN link: http://websvn.kde.org/?view=rev&revision=892951