Description of problem: When I run X I see /usr/bin/X using 100% of cpu (fortunately, I have 2 cpu's on this machine) Version-Release number of selected component (if applicable): This is on the recent fedora 10 release, with yum update (but I think also before) How reproducible: startx BTW, when the screen saver takes over, the usage drops. I have a cpu monitor running and I always see it about half user, half system. Steps to Reproduce: see above Actual results: see above Expected results: just running X without doing anything I should see approx 0% cpu usage Additional info: I tried strace for a few seconds and I get lots of this: setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 read(47, "L\1\5\0{\0\200\3\337\0\200\3Z\0\r\0031\0\r\0LD\25\0{\0\200\3\243\0\200\3X"..., 4096) = 4096 read(47, "n/gnLP\30\0{\0\200\3\243\0\200\3\4\0l\0020 0 3181"..., 4016) = 1464 read(47, 0x1d33590, 4096) = -1 EAGAIN (Resource temporarily unavailable) setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 select(256, [1 3 4 5 7 10 13 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48], NULL, NULL, {0, 0}) = 0 (Timeout) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 select(256, [1 3 4 5 7 10 13 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48], NULL, NULL, {0, 0}) = 0 (Timeout) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 select(256, [1 3 4 5 7 10 13 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48], NULL, NULL, {0, 0}) = 0 (Timeout) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 select(256, [1 3 4 5 7 10 13 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48], NULL, NULL, {0, 0}) = 0 (Timeout) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 select(256, [1 3 4 5 7 10 13 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48], NULL, NULL, {0, 0}) = 0 (Timeout)
*** This bug has been marked as a duplicate of bug 474586 ***
Please reopen this BUG since it has nothing to do with gnome-screensaver. I'm using a KDE only desktop and applications and I still experience this bug on fedora-rawhide (last yum update: 2009-02-19). Since I have 4-core CPU, the computer does not freeze, I can still use it normally (I don't know if the fact that I can't use CRTL+ALT+Fn has something to do with this...). kernel-2.6.29-0.124.rc5.fc11.x86_64 kdelibs-4.2.0-11.fc11.x86_64 xorg-x11-server-Xorg-1.5.99.902-12.fc11.x86_64 kdeplasma-addons-4.2.0-1.fc11.x86_64 ... The strace -p shows only this endless loop: ------------------------------------------------------------------------------ Process 8347 attached - interrupt to quit ioctl(5, TCFLSH, 0x2) = -1 EIO (Input/output error) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 select(256, [1 3 5 8 13 14 15 16 19 25 31 32 34], NULL, NULL, {990, 84000}) = 1 (in [5], left {990, 83996}) ioctl(5, TCFLSH, 0x2) = -1 EIO (Input/output error) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 select(256, [1 3 5 8 13 14 15 16 19 25 31 32 34], NULL, NULL, {990, 84000}) = 1 (in [5], left {990, 83997}) ioctl(5, TCFLSH, 0x2) = -1 EIO (Input/output error) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 select(256, [1 3 5 8 13 14 15 16 19 25 31 32 34], NULL, NULL, {990, 84000}) = 1 (in [5], left {990, 83997}) ioctl(5, TCFLSH, 0x2) = -1 EIO (Input/output error) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 select(256, [1 3 5 8 13 14 15 16 19 25 31 32 34], NULL, NULL, {990, 83000}) = 1 (in [5], left {990, 82997}) ioctl(5, TCFLSH, 0x2) = -1 EIO (Input/output error) ------------------------------------------------------------------------------ The GDB backtrace shows: (gdb) backtrace #0 0x00000031c6cded23 in __select_nocancel () from /lib64/libc.so.6 #1 0x00000000004e6c9a in WaitForSomething () #2 0x0000000000446df2 in Dispatch () #3 0x000000000042d045 in main () And X still uses 100% CPU for hours.
Sorry, then we need more information to further analyze your issue. Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
I can confirm, that FC10 (with all updates applied until today) shows the same problem (X with 100% on idle desktop). It is 100% regardless of KDE or GNOME and according to bug #474586 I removed gnome-screen-saver. The bug does not occur on the same hardware (IBM Thinkpad T43) with a preview version of FC11 (and FC9 was also OK). The same problem occurs on a second T43 with FC10. Attached you find the X server log file. There is no xorg.conf on my system as it runs in autoconfiguration mode.
Created attachment 333654 [details] X server log X server log for a system running X with 100% load.
I just want to confirm the above problem - I have a brand new FC10 install with all the latest updates running KDE and I noticed that 1 core was pinned at 100% usage for no apparent reason. I haven't had time to test if this happens immediately upon X starting or not, but strace showed the same results. The system in question is turned off at home right now, but I'll try to post more relevant details (including the X log) tonight.
(In reply to comment #6) OK, after a little poking around I found that FC10 had moved X to VT1. Not realizing that, I had set tty1 to start after prefdm. So I had both X and a getty running on VT1, which spiked the CPU. Turning it back off returned the CPU to normal. Now I just have to get used to not having a text console on VT1 like I do on all my other linux boxes...
YES! Indeed this solved the problem for me too. For other people with the same problem, do: rm /etc/event.d/tty1 reboot I will now file a bug report for initscripts, which contains that file.
Um, that's NOT what you want to do. Mine was borked because I EDITED IT MYSELF to start tty1 after prefdm. Before I did that I compared the tty1 and tty2 scripts, and the only different between them was that the tty1 file did not contain the following line: start on started prefdm You want/need it fo if you ever start up in non-graphcal mode, but with the move of X to VT1 in FC10, they don't start it if they start X.
Maybe it is a kind of race condition? I have machines which start graphical mode but still I can see a respawning "mingetty tty1". This interferes very much with X11 resulting in 100% cpu. On other machines I do not see a running mingetty (and also not a respawing mingetty). The only difference I can see are different Xorg drivers. Clearly removing getty on tty1 is a simple solution (with a minimal drawback from my point of view). So it fixes the problem for me and makes my laptop run for 2 hours instead of 30 minutes. However, finding a better solution is probably a good idea.
I filled bugzilla #490829 called "mingetty started on tty1 causing xorg to use 100% cpu". This bug is filled against initscripts instead of xorg which is the right component as far as i see.
I can confirm seeing this on a fully updated F-11. I'll change the version and follow up on bug 490829, which seems to have gone idle because Till has not responded.
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
I got this bug, with 100% CPU consumed by X, on a machine upgraded from F11 to F12. I then did a clean install thinking that would solve it but it didn't and I still have the same issue. KDE or GNOME makes no difference. strace -p shows a whole bunch of the stuff in the original bug report and in comment #2. On a laptop running F12 I do not have this issue. Deleting /etc/event.d/tty1 does solve the problem but I'd certainly like to have a better solution than this. Please let me know what additional information I need to provide. Thanks.
Had this problem as well... Looks like it can be solved using the event mechanism to stop tty1 when prefdm is started for runlevel 5. You get the tty1 when not in runlevel 5. Don't know if the respawn limit is actually necessary - had some issues at first. This solved my 100% cpu utilization issue and renters tty1 usable in other runlevels. diff -ur event.d.orig/tty1 event.d/tty1 --- event.d.orig/tty1 2009-10-27 16:11:39.000000000 -0400 +++ event.d/tty1 2009-11-23 23:46:03.097025786 -0500 @@ -2,6 +2,7 @@ # # This service maintains a getty on tty1 from the point the system is # started until it is shut down again. +# stop on run level 5 - X takes over start on stopped rc2 start on stopped rc3 @@ -9,7 +10,9 @@ stop on runlevel 0 stop on runlevel 1 +stop on runlevel 5 stop on runlevel 6 respawn +respawn limit 5 5 exec /sbin/mingetty tty1
The issue is that X is starting on tty1 when a tty is there. For the people above, what display manager are you using?
(In reply to comment #16) > The issue is that X is starting on tty1 when a tty is there. For the people > above, what display manager are you using? They look like coming from KDE world, so I would expect kdm, but they may have to have something even more weird ;)
I am using KDM. I yum groupinstalled the KDE packages and then created /etc/sysconfig/desktop with these two lines: DESKTOP="KDE" DISPLAYMANAGER="KDE" I had this same configuration with F11 on the same machine and it worked fine. I also currently have this same configuration on a different F12 machine and it works fine, so something else must be at play as well.
To explain: We intentionally don't always stop the getty on tty1 in runlevel 5, because of a large number of complaints when we initially did that, from people whose X sessions run on tty7, and therefore had a 'blank' tty1. The way X normally starts is that it takes the first new, available tty. For a case where mingetty's already started, that's normally tty7. We have code in plymouth that, on boot, if you're booting to runlevel 5, sets a flag for gdm so that it knows it can use tty1; gdm then starts X on tty1. If you do 'telinit 3; telinit 5' (or start in runlevel 3, and then change to runlevel 5), that flag is no longer there. So gdm starts X on the first available tty as normal. (Usually tty7) Ergo, if something is starting X on tty1 when there's already a mingetty there, it has a bug.
I'm running kdm + gnome. I boot to runlevel 3 and switch manually to 5 when things are stable (usually). I run kdm vs. gdm as I also use XDMCP. When I telinit 5, X is started on vt1 whilst mingetty is already there. So based on your explanation, I poked deeper. Seems that maybe /usr/share/config/kdm/kdmrc is misconfigured for a mingetty on tty1. At line 61 there is a comment stating that "A negative number means that the VT will be used only if it is free." The next line: ServerVTs=1. That seems to force X onto vt1. Next, at line 68, ConsoleTTYS=tty[2-6]. Thus the assumption that there is no mingetty running on tty1. I'd suggest changing line 65 to: ServerVTs=-1,-7; and then add "tty1" to line 68. However, I'm not at all sure that this solves everything for everyone. I think this would force X onto vt7 for those running a console on tty1; and prevent X from starting if there is something running on both tty1 and tty7. I haven't looked at the gdm equivalent logic as XDMCP had been busted and I haven't checked to see if it once again works.
> We have code in plymouth that, on boot, if you're booting to runlevel 5, sets a > flag for gdm so that it knows it can use tty1; gdm then starts X on tty1. This can't work for KDM. KDM takes a static option which tells it which tty to use. So we always set this to 1.
... then it probably should default to 7, not 1. I really don't want to push updates to older distributions that changes the behavior to force-logout sessions on tty1, for example.
We might also patch the special magic into KDM though. KDM needs work to seamlessly integrate with Plymouth anyway ("flickerfree boot"). I wonder what upstream will think of all this. (The upstream maintainer has been less than helpful in the past with getting ConsoleKit support merged, though I eventually managed to get that one in. The main issue was communicating what exactly needed fixing in the patch to be considered mergeable.)
FWIW, I believe bug 542138, which got closed as a duplicate of bug 470004, is actually related to this issue, not to bug 470004.
(In reply to comment #21) > > We have code in plymouth that, on boot, if you're booting to runlevel 5, sets a > > flag for gdm so that it knows it can use tty1; gdm then starts X on tty1. > > This can't work for KDM. KDM takes a static option which tells it which tty to > use. So we always set this to 1. Modifying kdm as I suggested in comment #20 does work - just tested it. Adding tty1 to the monitored ttys and making servervts=-1 restores proper function. In my case, kdm launches X on vt7, not vt1. If I take down tty1, then kdm launches onto tty1. It's a simple solution for those using kdm that doesn't interfere with gdm functionality.
Created attachment 374909 [details] Propopsed patch for kdm Patch based on my previous comment (25). This is working on my F12 box.
So that settings change is enough? Reassigning to kde-settings.
(In reply to comment #27) > So that settings change is enough? Reassigning to kde-settings. For kdm users, I would think yes. Not sure if this applies to gdm or anything else.
This bug seems to be about KDM only, GDM has special logic as described by Bill Nottingham in comment #19.
OK, spoke with halfline, and think we can use the same hack that gdm uses to know when transitioning from plymouth (and is ok to use the active vt). So, that (a small patch to kdebase-workspace/kdm) + the kdmrc change to ServerVTs=-1 should do the trick.
kde-l10n-4.3.4-1.fc12, kdeutils-4.3.4-2.fc12, kdetoys-4.3.4-1.fc12, kdesdk-4.3.4-1.fc12, kdepim-runtime-4.3.4-1.fc12, kdepim-4.3.4-1.fc12, kdeplasma-addons-4.3.4-1.fc12, kdenetwork-4.3.4-1.fc12, kdemultimedia-4.3.4-1.fc12, kdegraphics-4.3.4-1.fc12, kdegames-4.3.4-1.fc12, kdeedu-4.3.4-1.fc12, kdebindings-4.3.4-1.fc12, kdeartwork-4.3.4-1.fc12, kdeadmin-4.3.4-1.fc12, kdeaccessibility-4.3.4-1.fc12, kdebase-runtime-4.3.4-2.fc12, kdebase-4.3.4-1.fc12, kdepimlibs-4.3.4-1.fc12, kdelibs-experimental-4.3.4-1.fc12, kdelibs-4.3.4-1.fc12, phonon-4.3.80-2.fc12, kde-settings-4.3-15.1, kdebase-workspace-4.3.4-3.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kde-l10n kdeutils kdetoys kdesdk kdepim-runtime kdepim kdeplasma-addons kdenetwork kdemultimedia kdegraphics kdegames kdeedu kdebindings kdeartwork kdeadmin kdeaccessibility kdebase-runtime kdebase kdepimlibs kdelibs-experimental kdelibs phonon kde-settings kdebase-workspace'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13285
kde-l10n-4.3.4-1.fc11, soprano-2.3.1-1.fc11, kdeaccessibility-4.3.4-1.fc11, kdeadmin-4.3.4-2.fc11, kdeartwork-4.3.4-1.fc11, kdebindings-4.3.4-1.fc11, kdebase-4.3.4-1.fc11, kdebase-runtime-4.3.4-2.fc11, kdebase-workspace-4.3.4-1.fc11, kdeedu-4.3.4-1.fc11, kdegames-4.3.4-1.fc11, kdegraphics-4.3.4-1.fc11, kdelibs-experimental-4.3.4-1.fc11, kdemultimedia-4.3.4-1.fc11, kdenetwork-4.3.4-1.fc11, kdepim-4.3.4-1.fc11, kdepim-runtime-4.3.4-1.fc11, kdeplasma-addons-4.3.4-1.fc11, kdesdk-4.3.4-1.fc11, kdetoys-4.3.4-1.fc11, kdeutils-4.3.4-1.fc11, kde-settings-4.2-14, oxygen-icon-theme-4.3.4-1.fc11, kdepimlibs-4.3.4-1.fc11, kdelibs-4.3.4-3.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kde-l10n soprano kdeaccessibility kdeadmin kdeartwork kdebindings kdebase kdebase-runtime kdebase-workspace kdeedu kdegames kdegraphics kdelibs-experimental kdemultimedia kdenetwork kdepim kdepim-runtime kdeplasma-addons kdesdk kdetoys kdeutils kde-settings oxygen-icon-theme kdepimlibs kdelibs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-13342
kde-l10n-4.3.4-1.fc12, kdeutils-4.3.4-2.fc12, kdetoys-4.3.4-1.fc12, kdesdk-4.3.4-1.fc12, kdepim-runtime-4.3.4-1.fc12, kdepim-4.3.4-1.fc12, kdeplasma-addons-4.3.4-1.fc12, kdenetwork-4.3.4-1.fc12, kdemultimedia-4.3.4-1.fc12, kdegraphics-4.3.4-1.fc12, kdegames-4.3.4-1.fc12, kdeedu-4.3.4-1.fc12, kdebindings-4.3.4-1.fc12, kdeartwork-4.3.4-1.fc12, kdeadmin-4.3.4-1.fc12, kdeaccessibility-4.3.4-1.fc12, kdebase-runtime-4.3.4-2.fc12, kdebase-4.3.4-1.fc12, kdepimlibs-4.3.4-1.fc12, kdelibs-experimental-4.3.4-1.fc12, phonon-4.3.80-2.fc12, kde-settings-4.3-15.1, oxygen-icon-theme-4.3.4-1.fc12, kdelibs-4.3.4-3.fc12, kdebase-workspace-4.3.4-3.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kde-l10n kdeutils kdetoys kdesdk kdepim-runtime kdepim kdeplasma-addons kdenetwork kdemultimedia kdegraphics kdegames kdeedu kdebindings kdeartwork kdeadmin kdeaccessibility kdebase-runtime kdebase kdepimlibs kdelibs-experimental phonon kde-settings oxygen-icon-theme kdelibs kdebase-workspace'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13285
kde-l10n-4.3.4-1.fc12, kdeutils-4.3.4-2.fc12, kdetoys-4.3.4-1.fc12, kdesdk-4.3.4-1.fc12, kdepim-runtime-4.3.4-1.fc12, kdepim-4.3.4-1.fc12, kdeplasma-addons-4.3.4-1.fc12, kdenetwork-4.3.4-1.fc12, kdemultimedia-4.3.4-1.fc12, kdegraphics-4.3.4-1.fc12, kdegames-4.3.4-1.fc12, kdeedu-4.3.4-1.fc12, kdebindings-4.3.4-1.fc12, kdeartwork-4.3.4-1.fc12, kdeadmin-4.3.4-1.fc12, kdeaccessibility-4.3.4-1.fc12, kdebase-runtime-4.3.4-2.fc12, kdebase-4.3.4-1.fc12, kdepimlibs-4.3.4-1.fc12, kdelibs-experimental-4.3.4-1.fc12, phonon-4.3.80-2.fc12, kde-settings-4.3-15.1, oxygen-icon-theme-4.3.4-1.fc12, kdelibs-4.3.4-3.fc12, kdebase-workspace-4.3.4-3.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
kde-l10n-4.3.4-1.fc11, soprano-2.3.1-1.fc11, kdeaccessibility-4.3.4-1.fc11, kdeadmin-4.3.4-2.fc11, kdeartwork-4.3.4-1.fc11, kdebindings-4.3.4-1.fc11, kdebase-4.3.4-1.fc11, kdebase-runtime-4.3.4-2.fc11, kdebase-workspace-4.3.4-1.fc11, kdeedu-4.3.4-1.fc11, kdegames-4.3.4-1.fc11, kdegraphics-4.3.4-1.fc11, kdelibs-experimental-4.3.4-1.fc11, kdemultimedia-4.3.4-1.fc11, kdenetwork-4.3.4-1.fc11, kdepim-4.3.4-1.fc11, kdepim-runtime-4.3.4-1.fc11, kdeplasma-addons-4.3.4-1.fc11, kdesdk-4.3.4-1.fc11, kdetoys-4.3.4-1.fc11, kdeutils-4.3.4-1.fc11, kde-settings-4.2-14, oxygen-icon-theme-4.3.4-1.fc11, kdepimlibs-4.3.4-1.fc11, kdelibs-4.3.4-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
So, is it intended now that in a default install X will run on vt7 for kdm users. Thats the behaviour I see.
Here's how it's supposed to work: when booting with plymouth don't switch vt's, ie, use vt1. Not sure now if plymouth has a kms requirement (don't think so...). otherwise use first free vt (usually vt7).
ah, thanks. Its because I'm not using the plymouth graphical boot I'm getting X on vt7.
*** Bug 490829 has been marked as a duplicate of this bug. ***