Bug 475890 - KDM is set to use tty1 even if there's already a console on it
KDM is set to use tty1 even if there's already a console on it
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kde-settings (Show other bugs)
12
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
card_915GM
: Reopened, Triaged
: 490829 (view as bug list)
Depends On:
Blocks: fedora-x-target 490829
  Show dependency treegraph
 
Reported: 2008-12-10 17:26 EST by Donald Cohen
Modified: 2010-01-19 13:30 EST (History)
21 users (show)

See Also:
Fixed In Version: 4.3.4-1.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-28 15:08:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
X server log (67.36 KB, text/plain)
2009-03-01 11:26 EST, Dr. Tilmann Bubeck
no flags Details
Propopsed patch for kdm (580 bytes, patch)
2009-11-30 17:55 EST, Michael Breuer
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 206089 None None None Never

  None (edit)
Description Donald Cohen 2008-12-10 17:26:34 EST
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)
Comment 1 Matěj Cepl 2008-12-16 09:05:03 EST

*** This bug has been marked as a duplicate of bug 474586 ***
Comment 2 Cristiano Duarte 2009-02-19 12:10:52 EST
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.
Comment 3 Matěj Cepl 2009-02-19 12:53:31 EST
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.
Comment 4 Dr. Tilmann Bubeck 2009-03-01 11:25:51 EST
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.
Comment 5 Dr. Tilmann Bubeck 2009-03-01 11:26:46 EST
Created attachment 333654 [details]
X server log

X server log for a system running X with 100% load.
Comment 6 josh 2009-03-17 10:19:41 EDT
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.
Comment 7 josh 2009-03-17 20:11:55 EDT
(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...
Comment 8 Dr. Tilmann Bubeck 2009-03-18 04:01:49 EDT
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.
Comment 9 josh 2009-03-18 08:29:51 EDT
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.
Comment 10 Dr. Tilmann Bubeck 2009-03-18 09:48:10 EDT
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.
Comment 11 Dr. Tilmann Bubeck 2009-03-18 09:50:47 EDT
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.
Comment 12 Jason Tibbitts 2009-07-24 17:59:39 EDT
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.
Comment 13 Matěj Cepl 2009-11-05 13:21:03 EST
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.]
Comment 14 David 2009-11-18 03:33:34 EST
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.
Comment 15 Michael Breuer 2009-11-23 23:55:32 EST
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
Comment 16 Bill Nottingham 2009-11-25 17:25:06 EST
The issue is that X is starting on tty1 when a tty is there. For the people above, what display manager are you using?
Comment 17 Matěj Cepl 2009-11-25 17:34:34 EST
(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 ;)
Comment 18 David 2009-11-25 18:42:33 EST
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.
Comment 19 Bill Nottingham 2009-11-25 19:03:46 EST
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.
Comment 20 Michael Breuer 2009-11-25 20:01:18 EST
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.
Comment 21 Kevin Kofler 2009-11-30 16:51:01 EST
> 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.
Comment 22 Bill Nottingham 2009-11-30 16:59:57 EST
... 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.
Comment 23 Kevin Kofler 2009-11-30 17:17:46 EST
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.)
Comment 24 Kevin Kofler 2009-11-30 17:19:16 EST
FWIW, I believe bug 542138, which got closed as a duplicate of bug 470004, is actually related to this issue, not to bug 470004.
Comment 25 Michael Breuer 2009-11-30 17:36:56 EST
(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.
Comment 26 Michael Breuer 2009-11-30 17:55:07 EST
Created attachment 374909 [details]
Propopsed patch for kdm

Patch based on my previous comment (25). This is working on my F12 box.
Comment 27 Kevin Kofler 2009-11-30 18:07:27 EST
So that settings change is enough? Reassigning to kde-settings.
Comment 28 Michael Breuer 2009-11-30 18:40:37 EST
(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.
Comment 29 Kevin Kofler 2009-11-30 19:21:25 EST
This bug seems to be about KDM only, GDM has special logic as described by Bill Nottingham in comment #19.
Comment 30 Rex Dieter 2009-12-01 14:08:48 EST
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.
Comment 31 Fedora Update System 2009-12-17 23:22:42 EST
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
Comment 32 Fedora Update System 2009-12-21 23:41:09 EST
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
Comment 33 Fedora Update System 2009-12-21 23:51:55 EST
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
Comment 34 Fedora Update System 2009-12-28 15:08:18 EST
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.
Comment 35 Fedora Update System 2009-12-28 15:11:07 EST
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.
Comment 36 Roderick Johnstone 2010-01-14 05:42:41 EST
So, is it intended now that in a default install X will run on vt7 for kdm users. Thats the behaviour I see.
Comment 37 Rex Dieter 2010-01-14 10:17:44 EST
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).
Comment 38 Roderick Johnstone 2010-01-14 10:27:15 EST
ah, thanks. Its because I'm not using the plymouth graphical boot I'm getting X on vt7.
Comment 39 Bill Nottingham 2010-01-19 13:30:07 EST
*** Bug 490829 has been marked as a duplicate of this bug. ***

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