Bug 577482

Hi,

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

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...

Hi,

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

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.

Hi,

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

Hi,

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

Hi,

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 
racing"'

The issue is know by the maintainers.


Martin Kho

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

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.

Hi,

@Orion: 
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

Hi,

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

Ugh,

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

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

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.

Hi,

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

So both gdm and kdm are running tty7 ?

For me, gdm starts X just fine on tty1.

No, I've seen kdm running on vt3, vt4, vt5 and vt6. After rebooting a few times, Xorg was always sitting on tty7.

In comment #18 the rebooting was with gdm as displaymanager of course.

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?

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.

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:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2096216

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.

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.

Or... based on comment #18 , seems kdm is somehow picking the wrong tty, one it thinks is free (when in fact, is not free).

See also ml followup from orion (thanks!):
http://lists.fedoraproject.org/pipermail/devel/2010-April/134426.html

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
or
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.

Created attachment 404775 [details]
Don't pass vt argument to X

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

Hi,

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

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

Martin Kho

Hi,

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

Hi,

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

Thanks,

Martin

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...

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

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

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"

If you think plymouth is involved here, wouldn't it make sense to CC Ray Strode?

Indeed.  

Ray, we've been trying to get plymouth/kdm integration working, and noticed a recent commit
http://cvs.fedoraproject.org/viewvc/rpms/gdm/devel/plymouth.patch?r1=1.1&r2=1.2
that seemingly re-adds support for
/var/spool/gdm/...
stuff which I thought was supposed to be deprecated now.  What's the scoop?

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

So... moral of the story here is to continue to use the old/deprecated method of checking for
/var/spool/gdm/force-display-on-active-vt
?

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.

Gotcha, thanks!

*** Bug 575907 has been marked as a duplicate of this bug. ***

Please test using these 2 new builds:
https://koji.fedoraproject.org/koji/buildinfo?buildID=166818
https://koji.fedoraproject.org/koji/buildinfo?buildID=166815

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.

Hi,

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

yay, fail all around, correct behavior should be:
plymouth => vt1
not plymouth => vt7

kde-settings-4.4-13.fc13.1 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/kde-settings-4.4-13.fc13.1

kdebase-workspace-4.4.2-5.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/kdebase-workspace-4.4.2-5.fc13

Hi,

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

On my machine with kms I get X on vt1.  /var/spool/gdm is empty.  plymouth-gdm-hooks is not installed.

VESA driver has no KMS support, so getting the bar in plymouth is normal.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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.

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

(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

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

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.

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.

Thanks.

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.

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
https://fedoraproject.org/wiki/BugZappers

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.

Hi,

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

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

kdebase-workspace-4.4.2-5.fc13.i686
kde-settings-kdm-4.4-13.fc13.1.noarch.rpm
plymouth-0.8.2-2.fc13.i686

Using defaults:

$ cat /etc/kde/kdm/kdmrc | grep ServerVTs
ServerVTs=-1

$ cat /etc/kde/kdm/kdmrc | grep ConsoleTTYs=
ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6

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.

Hi Jaroslav,

$ cat /etc/kde/kdm/kdmrc | grep ServerVTs
ServerVTs=-1

$ cat /etc/kde/kdm/kdmrc | grep ConsoleTTYs=
ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6

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

BTW:
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
(...)

Hi,

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

kdebase-workspace-4.4.2-5.fc13.x86_64
plymouth-0.8.2-2.fc13.x86_64
kde-settings-kdm-4.4-13.fc13.1.noarch

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