Bugzilla – Bug 584919
Xorg uses 99% cpu after short period of inactivity with KDE 4.4
Last modified: 2010-08-31 07:53:36 UTC
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 SUSE/5.0.342.0-2.1 (KHTML, like Gecko) Chrome/5.0.342.0 Safari/533.2 I moved to KDE 4.4 (have the latest packages from KKFD) and after I unplug and then plug in the laptop Xorg will start using 99% CPU after the system is idle for a couple of minutes. The CPU usage seems to be normal when the system is not idle. If I log out and log back the problem goes away until I switch to battery and back to AC power. This is a T61 with Intel graphics. Reproducible: Always Steps to Reproduce: 1. Log in to KDE 2. Unplug AC power 3. Plug in AC power 4. Start top and let the system sit for a couple of minutes. Actual Results: Xorg will use 99% CPU. Expected Results: Xorg uses minimal CPU. Tasks: 218 total, 2 running, 216 sleeping, 0 stopped, 0 zombie Cpu(s): 5.3%us, 50.0%sy, 0.0%ni, 44.2%id, 0.0%wa, 0.0%hi, 0.5%si, 0.0%st Mem: 4027148k total, 3816748k used, 210400k free, 140k buffers Swap: 4192956k total, 9432k used, 4183524k free, 2452312k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20494 root 20 0 563m 157m 44m R 99 4.0 9:27.81 X 701 root 15 -5 0 0 0 S 11 0.0 52:55.97 phy0 10693 root 15 -5 0 0 0 S 0 0.0 1:41.11 events/1 22109 mtgibbs 20 0 147m 37m 19m S 0 1.0 1:33.09 chrome 23850 root 15 -5 0 0 0 S 0 0.0 0:00.21 usb-storage 24038 mtgibbs 20 0 2352 1064 768 R 0 0.0 0:03.69 top 1 root 20 0 1940 604 568 S 0 0.0 0:03.00 init 2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd 3 root RT -5 0 0 0 S 0 0.0 0:00.01 migration/0 4 root 15 -5 0 0 0 S 0 0.0 1:16.40 ksoftirqd/0 5 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/0 9 root 15 -5 0 0 0 S 0 0.0 0:00.90 events/0 11 root 15 -5 0 0 0 S 0 0.0 0:00.00 khelper 12 root 15 -5 0 0 0 S 0 0.0 0:00.00 netns 13 root 15 -5 0 0 0 S 0 0.0 0:00.00 async/mgr 14 root 15 -5 0 0 0 S 0 0.0 0:00.00 kintegrityd/0 16 root 15 -5 0 0 0 S 0 0.0 0:00.13 kblockd/0 18 root 15 -5 0 0 0 S 0 0.0 1:13.95 kacpid 19 root 15 -5 0 0 0 S 0 0.0 10:37.78 kacpi_notify
Screensaver involved? Which graphics driver is this? Might be the same as in Bug #580928, but that has been reported against openSUSE 11.3.
Screen saver is set to none. It is the Intel graphics driver, default settings. I think I have the 965GM chipset; I can attach the Xorg log later if necessary.
I doubt that you could see anything there. It might be interesting to see if that issue also occurs when using fbdev driver. Easiest would be to *boot* into *failsafe* mode to switch to this driver.
I booted into failsafe mode twice and the problem still occurred: top - 20:04:39 up 10 min, 3 users, load average: 0.93, 0.57, 0.30 Tasks: 169 total, 3 running, 166 sleeping, 0 stopped, 0 zombie Cpu(s): 30.7%us, 69.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.3%hi, 0.0%si, 0.0%st Mem: 4027148k total, 1607052k used, 2420096k free, 1192k buffers Swap: 4192956k total, 0k used, 4192956k free, 479392k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1539 root 20 0 82320 67m 4576 R 99.0 1.7 2:43.77 X 4072 mtgibbs 20 0 2352 1044 768 R 0.7 0.0 0:01.37 top 1564 root 20 0 3668 1140 976 S 0.3 0.0 0:00.23 hald-addon-stor 4132 mtgibbs 20 0 144m 34m 19m S 0.3 0.9 0:03.15 chrome 4134 mtgibbs 20 0 140m 29m 18m S 0.3 0.7 0:00.77 chrome 1 root 20 0 1940 664 576 S 0.0 0.0 0:00.50 init Xorg.0.log confirmed that it is using fbdev. I noticed that there are a bunch of KDE updates on the servers but I won't update until I get the okay from someone here that it won't affect the troubleshooting process.
(In reply to comment #4) > I noticed that there are a bunch of KDE updates on the servers but I won't > update until I get the okay from someone here that it won't affect the > troubleshooting process. I don't see how this should be related to KDE, so please go ahead.
*** Bug 583567 has been marked as a duplicate of this bug. ***
In my case, it's a Thinkpad T60 with Ati Mobility Radeon X1400 (or X1300?) graphics, using the radeonhd driver.
I also started to notice this issue immediately after upgrading to KDE 4.4.
I can confirm the same issue here with KDE 4.4.1 (11.2 KDE Factory packages) running on the Intel driver and an Intel GM45 graphics chipset.
*** Bug 580928 has been marked as a duplicate of this bug. ***
Thinkpad Z60t with Intel mobile 915 GM. openSUSE 11.2 with KDE 4.2 from factory repositories. 100% cpu usage after some idle time has been solved by adding repository http://download.opensuse.org/repositories/X11:/XOrg:/11.2/openSUSE_11.2/ and installing xorg-x11-driver-input 7.4-41.1-i586 and xorg-x11-driver-video 7.4-87.93-1-i586
(In reply to comment #11) > Thinkpad Z60t with Intel mobile 915 GM. > openSUSE 11.2 with KDE 4.2 from factory repositories. > > 100% cpu usage after some idle time has been solved by adding repository > http://download.opensuse.org/repositories/X11:/XOrg:/11.2/openSUSE_11.2/ > and installing > xorg-x11-driver-input 7.4-41.1-i586 > and > xorg-x11-driver-video 7.4-87.93-1-i586 The cpu usage problem has come back again. I don't know why it didn't happen for several hours after updating the xorg drivers. There must have been some other factor that I had altered. I'm back to trying to figure this thing out again.
Unfortunately I no longer have time to address bugs for already released openSUSE/SLE products. If possible verify whether the issue still exists with currently developed openSUSE Factory/SLE11-SP1. If it does please reopen the bugreport and set the product accordingly. Of course you can reopen the bugreport nevertheless, but that doesn't change the situation and the bugreport will remain open for the time being without being addressed.
I can reproduce this with openSUSE Factory on i945GM. Upstream bug report including Xorg strace: https://bugs.kde.org/show_bug.cgi?id=231628 The CPU load is only in Xorg, but stops as soon as kded4 is killed. However, it continues if kded4 is not killed, but all its modules are unloaded, leaving the kded4 process passive. Therefore I am trying to understand how kded4 is communicating with Xorg to cause the load. Any suggestions?
Sorry, the strace is in our thread here: http://lists.opensuse.org/opensuse/2010-03/msg00956.html
Not really. :-(
Also reported at http://forum.kde.org/viewtopic.php?f=66&t=86054
Also at http://forums.opensuse.org/get-help-here/applications/436173-very-high-cpu-usage-xorg-when-idle.html Comment #9 reports that the problem happens after resume from suspend to ram.
And as usual when you start playing with settings, the bug hides. My original settings that I could reproduce it with: Blank screen screensaver, enabled after 1 minute DPMS according to xset -q DPMS (Energy Star): Standby: 180 Suspend: 0 Off: 120 DPMS is Enabled Monitor is On Note that 'Monitor is On' even though it was idle more than 120 seconds.
Egbert: I can't reproduce the CPU usage with your patched Xorg, and haven't noticed any sideeffects yet; screensavers and auto-idle code in KDE using SYNC appear to work normally.
Hmm. Where can I find Egbert's patched Xorg?
home:eeich:branches:X11:XOrg (not sufficiently tested due to problems with intel in Factory) or home:eeich:branches:openSUSE:11.2 (tested)
Possibly related issue: https://bugs.kde.org/show_bug.cgi?id=230782 Have you tried disabling the powerdevil service in the KDE system settings ? Here is my config: openSUSE 11.2, but with KDE 4.4.2. Disabling powerdevil then log out, relogin, is a workaround. X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: openSUSE SUSE LINUX Current Operating System: Linux vincent 2.6.31.12-0.2-desktop #1 SMP PREEMPT 2010-03-16 21:25:39 +0100 i686 Build Date: 02 November 2009 12:05:39PM Graphic card is NVIDIA Geforce 9300M GS with proprietary driver version 195.36.15
Egbert is currently preparing a fix for openSUSE:Factory. He is reluctant to fix that issue also for openSUSE 11.2, since for that he would need to change the public Xext API, which is usually not a good idea. So for now 11.2 users need to disable powerdevil to address that issue.
Vincent: disabling powerdevil will work as a side-effect but the problem is in KIdleTime. Any other user of that class, eg RSIBreak, will also trigger the problem.
Fixed by SR #38450.
Created attachment 356167 [details] Testtool With the new xorg-x11-server package, you only get the timeout once and it is never fired again. I'm using the attached test.c to verify it. With the Milestone 5 package, the timeout is fired multiple times, but with the disadvantage that the CPU goes mad ;-) With the package containing the above fix, there's only one single timeout which never repeats.
Reopen, please see comment #27
Might sound like a stupid question, but how long is that single timeout? I mean is it that fatal?
Not sure if I understand that correctly...the test tool fires a timeout when the system is idle for 3 seconds. When there is user activity the timeout is reset and should fire again after 3 seconds. This happens with Milestone 5 but not with the new package. There is never a timeout again. The test tool basically does the same as what's used in powerdevil/kidletime.
Please note: This might as well just be an implementation error in powerdevil and the test tool, it's just my oberservation about what changed...
(In reply to comment #27) > Created an attachment (id=356167) [details] > Testtool > > With the new xorg-x11-server package, you only get the timeout once and it is > never fired again. I'm using the attached test.c to verify it. With the > Milestone 5 package, the timeout is fired multiple times, but with the > disadvantage that the CPU goes mad ;-) With the package containing the above > fix, there's only one single timeout which never repeats. Holger, thanks for your test case. My factory test box is grossly outdated as i found out so i'm in the process of updating it. You are saying that you only get the alarm once - this reads to me you don't ever get any other alarm even after a reset. This is strange as how I read the code the trigger gets readded to a counter every time the alarm is re-set. I need to check this more deeply once my box is updated.
Ok, the trigger didn't get readded to the counter when the alarm was changed. I've made a change and created a new package in home:eeich:XOrg:X11 package xorg-x11-server. The test program works as it did without the patch.
(In reply to comment #33) > Ok, the trigger didn't get readded to the counter when the alarm was changed. > I've made a change and created a new package in home:eeich:XOrg:X11 package > xorg-x11-server. The test program works as it did without the patch. Of course the 100% busy cycles on the cpu are no longer.
Thanks. Patch is now submitted to X11:XOrg and openSUSE:Factory. Therefore closing as fixed.
Egbert, please clarify, I understood the header change === the api change, and you were saying it shouldn't be a problem to backport for 11.2.
(In reply to comment #38) > Egbert, please clarify, I understood the header change === the api change, and > you were saying it shouldn't be a problem to backport for 11.2. X.Org as shipped with 11.2 has the structure SyncAlarm defined in syncstr.h which is part of the xextproto package which we ship with xorg-x11-proto-devel. However the part of the header where this structure is defined is protected by: #ifdef _SYNC_SERVER .. #endif this used to be defined in the server, an X library or user space program should never define this. To overcome the necessity to touch a proto package when a server internal structure changes the parts wrapped by above #ifdef are now (xserver 1.8) moved to a header contained in the server. The proto package has been updated as well. Thus there isn't really any client api change. Only the fact that a client visible X header historically contained some server internal structures. Thus doing this for 11.2 will not introduce any change to any API outside the server. Still the requirement to modify this header will require the proto package to be updated and in turn *all* packages depending on X headers will start to rebuild.
hi, sorry for spamming this thread, but you can't imagine how happy I am that this issue has been resolved! :) it is so annoying to have your laptop's battery being drained and fans going mad exactly at the time you want it to _save_ battery. thanks a lot for investigating this problem to the bone!
I tried upgrading Xorg to the one in the X11:Xorg repository for 11.2 and when I rebooted I only got the fbdev driver; not the intel driver. Is there still a problem with the intel driver?
(In reply to comment #41) > I tried upgrading Xorg to the one in the X11:Xorg repository for 11.2 and when > I rebooted I only got the fbdev driver; not the intel driver. Is there still a > problem with the intel driver? Most likely KMS is not active. KMS wasn't active on 11.2 kernel by default. If KMS is not available X falls back to fbdev driver.
So how I do I enable KMS? Does it require compiling a new kernel? I don't think I'm up to that.
Theoretically it would be enough to add i915.modeset=1 as kernel boot parameter, but most likely you need an updated kernel for better KMS support. In any case this is getting off-topic.
(In reply to comment #39) > Still the requirement to modify this header will require the proto > package to be updated and in turn *all* packages depending on X headers will > start to rebuild. So?
(In reply to comment #45) > (In reply to comment #39) > > Still the requirement to modify this header will require the proto > > package to be updated and in turn *all* packages depending on X headers will > > start to rebuild. > > So? They are reluctant to fix this issue because it would cause too many updates, if I understand correctly.
Not fixing a bug because the update would be too big, is a very bad reason.
I reproduce this bug in my openSUSE 11.3. I use KDE 4.5.0 and X.Org Server 1.9.0. After reboot X consumes 1-2 % CPU, but after computer idle time (monitor shut-down), X starts to consume 20-50 % on a kernel. If to restart process plasma-desktop (kquitapp plasma-desktop && plasma-desktop), X again consumes 1-2 % before following idle time of the computer. The bug as is played back on the version X.Org Server 1.8.0
Neither X.Org 1.9.0 nor KDE 4.5 is part of openSUSE 11.3.