Bug 577482 - X server hogs the CPU
Summary: X server hogs the CPU
Alias: None
Product: Fedora
Classification: Fedora
Component: kdebase-workspace
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
: 575907 (view as bug list)
Depends On:
Blocks: F13Blocker, F13FinalBlocker
TreeView+ depends on / blocked
Reported: 2010-03-27 12:07 UTC by Jaroslav Franek
Modified: 2010-04-26 14:02 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-04-26 14:02:15 UTC
Type: ---

Attachments (Terms of Use)
Don't pass vt argument to X (488 bytes, patch)
2010-04-06 19:34 UTC, Orion Poplawski
no flags Details | Diff

Description Jaroslav Franek 2010-03-27 12:07:48 UTC
Description of problem:

After logging into KDE, the X server started to hog the CPU. Almost 70% is kernel time. var/log/messages complains endlessly about tty main process being killed by QUIT signal and respawned. Ctrl+Alt+F? does not work (cannot get to tty?).

Version-Release number of selected component (if applicable):


How reproducible:

Just boot the computer and login into KDE.

Steps to Reproduce:
Actual results:

top output:

op - 12:55:03 up 14 min,  5 users,  load average: 1.96, 2.27, 1.58
Tasks: 162 total,   2 running, 159 sleeping,   0 stopped,   1 zombie
Cpu(s): 26.9%us, 70.8%sy,  0.3%ni,  0.7%id,  1.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   1536948k total,   836020k used,   700928k free,    52880k buffers
Swap:  3080184k total,        0k used,  3080184k free,   335880k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                        
 1472 root      20   0 62820  19m 5756 R 86.7  1.3  10:00.62 X                              


Mar 27 12:58:36 localhost init: tty (/dev/tty6) main process (2666) killed by QUIT signal
Mar 27 12:58:36 localhost init: tty (/dev/tty6) main process ended, respawning
Mar 27 12:58:36 localhost init: tty (/dev/tty6) main process (2668) killed by QUIT signal
Mar 27 12:58:36 localhost init: tty (/dev/tty6) main process ended, respawning
Mar 27 12:58:38 localhost init: tty (/dev/tty6) main process (2670) killed by QUIT signal
Mar 27 12:58:38 localhost init: tty (/dev/tty6) main process ended, respawning
Mar 27 12:58:45 localhost init: tty (/dev/tty6) main process (2672) killed by QUIT signal
Mar 27 12:58:45 localhost init: tty (/dev/tty6) main process ended, respawning
Mar 27 12:58:45 localhost init: tty (/dev/tty6) main process (2674) killed by QUIT signal
Mar 27 12:58:45 localhost init: tty (/dev/tty6) main process ended, respawning
Mar 27 12:58:54 localhost init: tty (/dev/tty6) main process (2676) killed by QUIT signal
Mar 27 12:58:54 localhost init: tty (/dev/tty6) main process ended, respawning

... this continues endlessly

Expected results:

X server does not hog the CPU.
tty? accessible
/var/log/messages clean

Additional info:

Almost fresh Fedora 13 Alpha installation on a laptop, using Dual screen with Radeon 9000, KMS.

Yesterday after yum update and reboot the X server once again behaved correctly (I thought the issue was fixed by the update), but today it started again to hog the CPU.

The X server does not hog the CPU when showing the logging screen. The problem appears to start when launching the KDE session.

Comment 1 Martin Kho 2010-03-30 09:11:20 UTC

I've installed F13 KDE nightly build (20100328) in VirtualBox. It's using the vesa driver (not from the VirtualBox Guest Additions). I experience the same high cpu usage and the messages in /var/log/messages.

1) What I've seen is that X can start on different vt's. Now it's running on vt5 causing messages in /var/log/messages to be:
tty (/dev/tty5) main process ended, respawning
tty (/dev/tty5) main process (2676) killed by QUIT signal
2) Tried to boot into runlevel 3 and start X (not startX). No high cpu usage. X starts on vt7
3) A while ago there was a report on high cpu usage in relation to KDM and vt-switching, see [1]

Hope this info is relevant and helps.

Martin Kho

[1] https://bugzilla.redhat.com/show_bug.cgi?id=475890

Comment 2 Jaroslav Franek 2010-03-30 09:27:30 UTC
Hi, I have found an interesting workaround :-)

When I boot the machine, wait for X server graphical login screen. Then go to text console by e.g. Ctrl+Alt+F2, wait for the text console to appear and then go back to graphical login screen (in my case Ctrl+Alt+F7) and login into KDE - the issue is gone. Tried several times, this trick works for me.

However, if I boot the machine, wait for the graphical login screen and immediately log into KDE, the X server starts hog the CPU. Then switching to text terminals cease to work, and in one case I was left with running computer but completely black screen with no way of interaction - had to use "RESET button" as in old Windows days...

Comment 3 Martin Kho 2010-03-30 22:02:10 UTC

I've followed the procedure Bill Nottingham described in Comment #19 in the report I mentioned in comment #1:

"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)"

I booted to runlevel 3 logged in and issued telinit 5. X started on vt7 and the high cpu usage didn't happen.

So it looks like that the patch Michael Breuer proposed in comment #26 in the same report no longer works:
"Adding tty1 to the monitored ttys and making servervts=-1 [in kdmrc] restores proper function. In my case, kdm launches X on vt7, not vt1."[...]= my add.

I'm not sure if this analyses is right, but I'll ask on the kde mailing list of some one else see high cpu usage in f13.

Martin Kho

Comment 4 Orion Poplawski 2010-03-30 22:20:29 UTC
Seeing the same thing here with kdm.  So who is to blame here?  Is kdm running before the migetty on one of the ttys?  Upstart ordering?

Also, often times it become impossible to switch virtual terminals.

Comment 5 Martin Kho 2010-03-31 07:56:27 UTC

Tried running without Plymouth. No change. For what I can see in kdmrc, nothing has been changed there. Upstart can be a good candidate.

Any idea how I can test this?

Martin Kho

Comment 6 Martin Kho 2010-03-31 08:35:22 UTC

Reverting the changes made in report #475890 (ServerVTs=-1 and add "tty1") 'solves'the problem. X will - always? - sit on vt1. If I interpret 
"Fix start-ttys for the correct number of ttys, and for X-on-tty1." [1] correctly this is supposed to happen.

Change /etc/kde/kdm/kdmrc:

* ServerVTs=-1 -> ServerVTs=1
* ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6 -> ConsoleTTYs=tty2,tty3,tty4,tty5,tty6

If I'm wrong I like to hear it.

Martin Kho

[1] http://git.fedorahosted.org/git/?p=initscripts.git;a=log;h=refs/heads/upstart-0.6.0-branch

Comment 7 Martin Kho 2010-04-01 08:56:22 UTC

Although the 'workaround' in comment #6 is working for me, it is not recommended according to Rex Dieter: 'Forcing VT1 is what caused the "old issue of X and tty 

The issue is know by the maintainers.

Martin Kho

Comment 8 Orion Poplawski 2010-04-01 17:50:59 UTC
Do we know who's fault this is?  Other bug reports?

Hit another possible variant of this today where X didn't come up at boot.  Xorg.0.log showed:

[    51.017] (++) using VT number 7

[    80.436] 
Fatal server error:
[    80.438] xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call

Comment 9 Jaroslav Franek 2010-04-01 18:19:11 UTC
Re comment #8:

Looks almost like bug #551310 I had reported for Fedora 12 few months ago. That time there were troubles with ServerVTs=-1 settings. The cause was missing /var/spool/gdm file (it was missing in one of KDE rpms). It only affected people that had KDE but did not have Gnome installed.

Comment 10 Martin Kho 2010-04-01 18:34:29 UTC

Based on what Kevin Kofler said: "Yes. Plymouth works differently in F13, so the KDM Plymouth patch needs to be updated. We haven't done that yet."

I suppose KDM is the culprit.

Martin Kho

Comment 11 Martin Kho 2010-04-02 17:42:20 UTC

Tried to boot with rhgb (=plymouth?) removed from the kernel line. This didn't solve the issue. So I doubt if a 'KDM Plymouth patch' will do the job.

Martin Kho

Comment 12 Rex Dieter 2010-04-02 17:53:06 UTC

xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system

implies something similar to the old bug alright.

I'll have to dig into the old report, and refresh my memory of all the issues involved.  

I'll also be working on kdm/plymouth integration this weekend (hopefully, if I have time).

Comment 13 Orion Poplawski 2010-04-02 17:59:17 UTC
Sorry, probably should keep the VT_WAITACTIVE issue separate.  There is Bug 577896 already open for that (though not sure if the original reporter is using kdm).

Comment 14 Rex Dieter 2010-04-02 18:17:06 UTC
An interesting test for those experiencing this,

yum intall gdm

and reboot, and see if problem is reproducible when using gdm or not.

If so, kdm is (most likely) innocent.

Comment 15 Martin Kho 2010-04-02 19:03:25 UTC

Sorry Rex, GDM doesn't have the issue. tty[2-7] are defined and Xorg is running on tty7. I'm afraid KDM is causing the issue ;-(

Martin Kho

Comment 16 Rex Dieter 2010-04-02 19:16:47 UTC
So both gdm and kdm are running tty7 ?

Comment 17 Orion Poplawski 2010-04-02 19:25:03 UTC
For me, gdm starts X just fine on tty1.

Comment 18 Martin Kho 2010-04-02 19:45:37 UTC
No, I've seen kdm running on vt3, vt4, vt5 and vt6. After rebooting a few times, Xorg was always sitting on tty7.

Comment 19 Martin Kho 2010-04-02 19:48:18 UTC
In comment #18 the rebooting was with gdm as displaymanager of course.

Comment 20 Orion Poplawski 2010-04-02 22:35:55 UTC
I think it is interesting that gdm starts X with a command like:

/usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-84TSn3/database -nolisten tcp

while kde does:

/usr/bin/X -nr -nolisten tcp :0 vt7 -auth /var/run/kdm/A:0-CiH7gZ

So kdm is specifying a vt and gdm is not?

Comment 21 Jaroslav Franek 2010-04-05 19:05:17 UTC
Latest batch of updates (incl. Plymouth and some KDE stuff) brought my system into even worse condition: I do not even get login screen, computer frozen, screen contains really corrupted image from Plymouth theme (I wonder where all that artefacts and the nice purple color are coming from...).

The way to get workable KDE session is to boot into mode 3, then go via telinit 5 to mode 5. Then it works well, even without hogging the CPU.

So it seems Plymouth --> kdm transition is striking back, again.

Comment 22 Orion Poplawski 2010-04-05 22:27:20 UTC
Well, for grins I made a build of kdm that doesn't pass the "vt#" argument to X.  On one machine on which plymouth fails to start but which the current kdm started X on vt5, X now starts fine on vt7.  On another machine, X still craps out with "xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call".

Build is here:


if anyone wants to try it out.  No idea is this is the correct approach, just noticing that gdm does not pass "vt#" to X.

Comment 23 Rex Dieter 2010-04-05 23:24:15 UTC
It's almost certainly plymouth (or X?) to blame here it seems, but adding plymouth integration to avoid the vt switch for kms-enabled drivers may well mitigate the damage.

Comment 24 Rex Dieter 2010-04-06 15:58:35 UTC
Or... based on comment #18 , seems kdm is somehow picking the wrong tty, one it thinks is free (when in fact, is not free).

Comment 25 Rex Dieter 2010-04-06 16:02:03 UTC
See also ml followup from orion (thanks!):

ajax suggests that X is indeed capable of finding the first free tty itself, so perhaps we can either
1. compare X's and kdm's methods of finding free tty's, and fix accordingly
2. drop kdm's find-free-tty detection, and just let X do it.

I'm of a mind to opt for 2, at this point (similar to the approach taken in comment #22 ).  less code for the win.

Comment 26 Orion Poplawski 2010-04-06 19:34:08 UTC
Created attachment 404775 [details]
Don't pass vt argument to X

FWIW - this is the patch I used in my test build.

Comment 27 Martin Kho 2010-04-06 20:54:52 UTC

I can confirm that Orion's patch is working. No high cpu usage.

Great work Orion .. if this fixes the issue :-)

Martin Kho

Comment 28 Martin Kho 2010-04-08 08:58:32 UTC

Today KDE was updated to kde 4.4.2. To 'solve' the 'cpu-hog' I installed kdebase-workspace 4.4.2-3 (all packages) from koji. For me this build didn't solve the issue. (Kevin dropped the patch in 4.4.2-2). I'm not sure if it is relevant, but plymouth is failing in VirtualBox (assertion failure [1]). Going back to 4.4.2-2 for now.

Plymouth version: plymouth-0.8.1-3.fc13.x86_64

Martin Kho

[1] https://bugzilla.redhat.com/show_bug.cgi?id=577836

Comment 29 Martin Kho 2010-04-08 13:07:19 UTC

Have plymouth running again (had to rebuild initramfs). And retried kdebase-workspace 4.4.2-3. Now it's working really smooth. Nice work Kevin :-)



Comment 30 Jaroslav Reznik 2010-04-08 14:32:51 UTC
4.4.2-3 leads to nice x server usage but for some reason transition from plymouth with splash screens to x fails - f stays forever...

Comment 31 Kevin Kofler 2010-04-08 16:27:39 UTC
So we have 2 problems now:
* bad tty selection without graphical Plymouth. Can you verify that ServerVT is set to -1 (minus 1) in the config file, not to 1? If it's set to -1 and KDM is not picking the correct VT, I guess we need to readd some version of the patch in 4.4.2-2, unless we can fix KDM's tty selection logic. But the patch in 4.4.2-2 is not good as is, as it will make X use a different VT than KDM thinks it uses, which confuses stuff like the ConsoleKit registration.
* Plymouth transition not working properly (comment #30).

Comment 32 Martin Kho 2010-04-08 17:27:21 UTC
Hi Kevin,

In /etc/kde/kdm/kdmrc I have (default):

* ServerVTs=-1
* ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6

With Plymouth enabled : X sits on vt7
With Plymouth disabled (removed rhgb): X sits on vt3, vt5 ... (cpu-hog)

Martin Kho

Comment 33 Orion Poplawski 2010-04-08 22:58:17 UTC
With kdm-4.4.2-3:
* Without plymouth I'm getting X on vt7.
* With plymouth I get stuck - X crash with "xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system"

Comment 34 Adam Williamson 2010-04-09 17:11:28 UTC
If you think plymouth is involved here, wouldn't it make sense to CC Ray Strode?

Comment 35 Rex Dieter 2010-04-10 21:13:52 UTC

Ray, we've been trying to get plymouth/kdm integration working, and noticed a recent commit
that seemingly re-adds support for
stuff which I thought was supposed to be deprecated now.  What's the scoop?

Comment 36 Ray Strode [halfline] 2010-04-12 18:35:41 UTC
Hey Rex,

It's deprecated upstream, but we're using the deprecated mode in Fedora at the moment.

Bill has a set of initscripts changes to change over to the new way, but they haven't landed yet because the version of upstart they were initially written in had a bug that prevented them from working (among other reasons)

that commit isn't readding support, it's moving the implementation of the support from one patch file to another (and in the process adding a new hunk to the patch which erroneously got dropped at some point).

Comment 37 Rex Dieter 2010-04-12 18:57:44 UTC
So... moral of the story here is to continue to use the old/deprecated method of checking for

Comment 38 Ray Strode [halfline] 2010-04-12 19:08:18 UTC
For now, yea.  It's going to stay working for the foreseeable future.  Even when things do switch over to the new way, it will be decidable on a per Display Manager basis.

GDM right now supports either way.  That's an option as well.

Comment 39 Rex Dieter 2010-04-12 19:12:31 UTC
Gotcha, thanks!

Comment 40 Mattia Verga 2010-04-13 17:50:21 UTC
*** Bug 575907 has been marked as a duplicate of this bug. ***

Comment 42 Rex Dieter 2010-04-13 18:12:41 UTC
Fwiw, the newer kde-settings-kdm and kdm packages is our first try at getting plymouth integration working.

I still think there's a race in kdm free tty-checking code, which non plymouth/kms folks may continue to experience this.

Comment 43 Martin Kho 2010-04-13 20:02:55 UTC

I've tested the koji builds:

* With Plymouth X sits on vt7, cpu normal usage
* Without Plymouth X sits on vt5 ..., high cpu usage

Martin Kho

Comment 44 Rex Dieter 2010-04-13 20:11:58 UTC
yay, fail all around, correct behavior should be:
plymouth => vt1
not plymouth => vt7

Comment 45 Fedora Update System 2010-04-13 20:23:21 UTC
kde-settings-4.4-13.fc13.1 has been submitted as an update for Fedora 13.

Comment 46 Fedora Update System 2010-04-13 20:26:56 UTC
kdebase-workspace-4.4.2-5.fc13 has been submitted as an update for Fedora 13.

Comment 47 Martin Kho 2010-04-13 20:39:29 UTC

Not sure if it's relevant, but I get the 'bar' (non-kms?) version of Plymouth and not the 'F'-version. Using the vesa driver.

Martin Kho

Comment 48 Orion Poplawski 2010-04-13 20:44:07 UTC
On my machine with kms I get X on vt1.  /var/spool/gdm is empty.  plymouth-gdm-hooks is not installed.

Comment 49 Adam Williamson 2010-04-13 20:48:49 UTC
VESA driver has no KMS support, so getting the bar in plymouth is normal.

Fedora Bugzappers volunteer triage team

Comment 50 Kevin Kofler 2010-04-13 21:22:13 UTC
If you're getting the text-mode bar in Plymouth, it's normal for KDM to start on vt7. You're only supposed to get vt1 if you use the graphical Plymouth.

Comment 51 Martin Kho 2010-04-13 21:37:34 UTC
Thanks Kevin for the info.

Hope this info will not muddle this thread, but I tested the corresponding packages for F14 (rawhide). Using the graphical Plymouth (KMS-Nouveau), X sits on vt7.

* plymouth-0.8.1-3.fc13.x86_64
* kdebase-workspace-4.4.2-5.fc14.x86_64
* kde-settings-4.5-1.fc14.1.noarch

Martin Kho

Comment 52 Karel Volný 2010-04-14 13:36:45 UTC
(In reply to comment #41)
> Please test using these 2 new builds:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=166818
> https://koji.fedoraproject.org/koji/buildinfo?buildID=166815    

this fixed the problem for me, thanks

Comment 53 Fedora Update System 2010-04-15 03:13:05 UTC
kdebase-workspace-4.4.2-5.fc13 has been pushed to the Fedora 13 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 kdebase-workspace'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kdebase-workspace-4.4.2-5.fc13

Comment 54 Fedora Update System 2010-04-16 23:43:11 UTC
kdebase-workspace-4.4.2-5.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 55 Jaroslav Franek 2010-04-17 19:20:53 UTC
The update solved the issue for me: plymouth -> kdm transition gets me to the KDE login screen and I can log-in without X server eating CPU. KDE sits on vt1 as expected.


Comment 56 Fedora Update System 2010-04-20 13:03:34 UTC
kde-settings-4.4-13.fc13.1 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 57 Adam Williamson 2010-04-23 17:51:26 UTC
Discussed at today's blocker bug review meeting. Since it looks like the fixes for this have gone to stable already, we think the bug should be closed - we're not sure why it's stuck at ON_QA, probably a Bodhi hiccup. We attempted to check in with Kevin before closing it, but he wasn't around, so we'll go ahead and close. Please re-open the bug if there's a reason it's not closed yet. thanks!

Fedora Bugzappers volunteer triage team

Comment 58 Kevin Kofler 2010-04-23 18:01:14 UTC
Well, the issue with graphical Plymouth enabled seems to be fixed (see comment #55), though comment #51 appears to claim the opposite (maybe there's something particular about the setup in comment #51?).

But there still seems to be the issue with free VT detection (which triggers in the non-Plymouth case) as per comment #43.

Comment 59 Martin Kho 2010-04-24 16:48:01 UTC

About comment #51: It's 'just an updated F12 to F14' no particularities. What I see when I boot into the F14 partition is that first a lot of kernel messages are scrolling over the screen. Next Plymouth kicks in, in graphical mode. X sits on vt7. But, based on comment #51 F13 can never be blocked IMHO? 

About Comment #43: X still sits on vt7

Martin Kho

Comment 60 Jaroslav Franek 2010-04-25 10:59:31 UTC
Tested several options, here are the results:

rhgb   nomodeset   KDE
 Y        N        vt1   (default case, no CPU hogging)
 N        N        vt1
 Y        Y        vt1
 N        Y        vt1


Using defaults:

$ cat /etc/kde/kdm/kdmrc | grep ServerVTs

$ cat /etc/kde/kdm/kdmrc | grep ConsoleTTYs=

Note there is no tty7 in the default configuration.

About comment #43: Martin, what are your settings in kdmrc? Please could you post results of the two above commands?

It seems to me that this issue is no longer blocking F13.

Comment 61 Martin Kho 2010-04-26 10:49:48 UTC
Hi Jaroslav,

$ cat /etc/kde/kdm/kdmrc | grep ServerVTs

$ cat /etc/kde/kdm/kdmrc | grep ConsoleTTYs=

I'm running F13 in VirtualBox-OSE-3.1.4-1.fc12.x86_64 with the vesa-driver. It's fully updated, no proprietary stuff, no extra software installed, selinux enabled, all defaults.

I'll try running a current LiveCD from an USB-stick and see what happens.

Martin Kho

In /var/log/boot.log I see: udev-work[366]: '/usr/bin/vmmouse_detect' unexpected exit with status 0x000b

On the kernel command line I have (default):
ro root=/dev/mapper/vg_ps1866-lv root rd_LVM_LV=vg_ps1866/lv_root rd_NO_LUKS rd_no_MD rd_NO_DM LANG=en_US.UTF8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us noiswmd rhgb quiet

In Xorg.0.log:
(II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so
(II) Module vesa: vendor="X.Org Foundation"
        compiled for 1.8.0, module version = 2.3.0
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 7.0
(II) VESA: driver for VESA Chipsets: vesa
(++) Using VT number 7

Comment 62 Martin Kho 2010-04-26 13:06:08 UTC

Running most current nightly-compose (20100423) from an USB-stick now. X is sitting on VT 7 ;-(. X-driver is nouveau (nVidia Corporation G73 [GeForce 7600 GS] rev 161). No CPU hogging.

Is there a way that the VT setting can be manipulated?

Martin Kho


Comment 63 Rex Dieter 2010-04-26 14:02:15 UTC
This is getting muddled in multiple issues, so let's consider this particular issue (per subject and the blocker) squashed.

Anyone seeing X *not* start on vt1 or vt7, please open a new bug, thanks.

For those of you with kms-enabled drivers with X not starting properly on vt1, see possibly related bug #585250 (which I'm personally experiencing).

Note You need to log in before you can comment on or make changes to this bug.