Bug 194558 - gdm is not reusing the lowest available vt (at least with multiple servers)
gdm is not reusing the lowest available vt (at least with multiple servers)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-13 23:33 EDT by Michal Jaegermann
Modified: 2009-12-18 00:52 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 00:52:42 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)

  None (edit)
Description Michal Jaegermann 2006-06-13 23:33:53 EDT
Description of problem:

(resubmitted bug 194834 with a report lost due to a hardware failure)

On a machine where '[servers]' section of /etc/gdm/custom.conf
looks like this:

[servers]
0=Standard
1=Standard

gdm, when started (assuming not modified /etc/inittab) runs
'/usr/bin/Xorg :0' on vt7 and '/usr/bin/Xorg :1' on vt8.  As expected
and so far so good.  Now after a session on ':0', terminated, gdm
restarts and - surprise - we have '/usr/bin/Xorg :0' on vt9 with
vt7 not used by anything as far as I can tell.  Not the end of the
world but quite annoying if one is switching between logons on
different servers and it is necessary to "hunt" for a login screen
or a session.  This was not the case in the past (gdm used with FC3
and earlier did not have that nasty habit and a ':0' server was
always running on vt7).

Even with ':0' on vt9 ':1' tends to stay on vt8, thankfully, although
this does not look like an absolute rule and I already have seen
a server running on vt10 with a lot of room below.  This looks like
hard to reproduce while skipping vt7 is practically guaranteed.
OTOH the only sure way to move servers back to lower vt's seems to be
to get out of level 5 and get back.  Say 'telinit 3' followed by
'telinit 5'.  Something as drastic as reboot will help too. :-)

Explicitely setting 'FirstVT' and 'VTAllocation' (to 'true' or 'false'
for the latter) does not seem to have any real consequences.  Something
nasty, like 'FirstVT=6', also does not help.

Version-Release number of selected component (if applicable):
gdm-2.14.8-1 and earlier in FC5 too

How reproducible:
too easily - sigh!
Comment 1 Michal Jaegermann 2006-06-21 15:18:15 EDT
As a matter of fact, when I started to pay attention, this "jumping"
to higher vt's happens also when only one server is running.  Only
that this is not so visible/annoying if one is always using a graphic
desktop without excursions to a text console.
Comment 2 Ray Strode [halfline] 2008-03-18 14:34:23 EDT
Hi,

We no longer support Fedora Core 5 and I am currently trying to get my open bug
count down to a more manageable state.  I'm going to close this bug as WONTFIX.
 If this issue is still a concern for you, would you mind trying to reproduce on
a supported version of Fedora and reopening?

(this is a mass message)
Comment 3 Michal Jaegermann 2008-03-18 15:30:11 EDT
> If this issue is still a concern for you ...

Oh, sure.  This is from a Fedora 8 machine right at this moment:

# pgrep -f -l gdm | grep vt
9148 /usr/bin/X :1 -br -audit 0 -auth /var/gdm/:1.Xauth -nolisten tcp vt11
10180 /usr/bin/X :0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt9

That with a "regular" vt7 not in use.

On various occassions this is a real PITA although not a killer issue.
On Fedora 7 that happens as well.

That may go in a future Fedora 9 simply because gdm used there
cannot provide multiple servers (hard to tell if this is really true
as so far there is _no_ documentation for that beast).

You still want that as WONTFIX?
Comment 4 Ray Strode [halfline] 2008-03-18 15:34:38 EDT
Seems like there's a race between the old X server exiting and the new one
starting up.  It should always pick the lowest available vt, so it must not
notice that it is available.
Comment 5 Michal Jaegermann 2008-03-18 16:49:16 EDT
> Seems like there's a race ...
Apparently so although "naive" remedies, like an extra 'sleep', were
not that helpful when I tried the last time.

This may happen also with one server in use but it is harder to trigger
and no so noticeable.
Comment 6 Michal Jaegermann 2008-03-18 16:55:08 EDT
Oh, I should likely add that playing with 'FirstVT=..' and
'VTAllocation=..' in a [daemon] section of /etc/gdm/custom.conf
also did not have any discernible effects on the problem.

Comment 7 Bug Zapper 2008-11-26 01:58:55 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Michal Jaegermann 2008-11-28 20:21:49 EST
This bug went from an annoyance to a serious PITA.  After a seriously demented switch of the first instance of gdm to vt1, but only directly after a boot, the next instance of gdm may appear anywhere.  Maybe on vt7, or on vt8 or maybe higher.  Just tried with gdm-2.24.0-12.fc10.

To make that even more "interesting" with older version one could at least find it using, say, 'pgrep -f -l gdm'.  Currently this does not say where to look so the only option left is "hunt-and-peek".  Just lovely!
Comment 9 Ray Strode [halfline] 2008-12-01 14:41:12 EST
Does the user-switcher applet work?


ck-list-sessions should tell you which VTs the active sessions are running on.
Comment 10 Michal Jaegermann 2008-12-02 20:06:00 EST
> Does the user-switcher applet work?

It does but:
  - it takes waaay too much of a valuable panel space for a user with a weak vision requiring much bigger fonts then tiny default ones
  - it helps zero if you want to switch between running sessions of few users
  - it actually quickly helped to create a mess when it was really unclear what may be running where
  - after a short experiment with it right now I got into a situation when first attempts to switch consoles first was showing a gdm login screen everywhere and now it locked up; no mouse, no keyboard, some scrambled garbage at the top of a screen and a weird square in the middle with a necessity of a power switch if not that detail that a machine can be reached over a network.

In the situation described in the last point I see that all gdm related processes
are in either in S, or Ssl or Ss+ states and nothing is moving. 'ck-list-sessions' shows only one session, 10, with "unix-user = '42'", i.e. gdm
and /dev/tty7.  Quite less than useful.  'pkill -f gdm' does restore some sanity but an attempt to get a text console immediately locks up everything once again.

> ck-list-sessions should tell you which VTs ...

Thanks for that piece of info.  It could be useful.
Comment 11 Michal Jaegermann 2008-12-02 20:15:59 EST
Err... it appears that this happens courtesy of user-switcher:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
IP: [<ffffffffa0041e5b>] radeon_cp_init_ring_buffer+0x234/0x521 [radeon]
PGD 8080067 PUD c9e1067 PMD 1d860067 PTE 0
Oops: 0000 [1] SMP 
CPU 0 
Modules linked in: autofs4 fuse sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_fi
lter ip6_tables ipv6 ext2 dm_multipath uinput ata_generic ppdev pata_acpi snd_vi
a82xx snd_via82xx_modem snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_se
q_midi_event snd_seq ns558 snd_pcm_oss gameport snd_mixer_oss snd_mpu401 floppy 
snd_pcm snd_mpu401_uart snd_timer snd_rawmidi k8temp snd_seq_device snd hwmon sn
d_page_alloc pcspkr soundcore i2c_viapro e100 mii pata_via sata_via skge parport
_pc parport shpchp firewire_ohci firewire_core crc_itu_t sata_promise radeon drm
 i2c_algo_bit i2c_core [last unloaded: freq_table]
Pid: 3005, comm: Xorg Tainted: G   M      2.6.27.5-117.fc10.x86_64 #1
RIP: 0010:[<ffffffffa0041e5b>]  [<ffffffffa0041e5b>] radeon_cp_init_ring_buffer+
0x234/0x521 [radeon]
RSP: 0018:ffff88001dd9fe18  EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff88001d962000 RCX: 0000000000000009
RDX: 0000000000000000 RSI: 00000000ffff0000 RDI: ffff88001d962000
RBP: ffff88001dd9fe28 R08: ffff88001dd9fc88 R09: 000000408100e9bf
R10: 00000014784a4914 R11: 0000000100000000 R12: ffff88001d964000
R13: 0000000000006458 R14: ffff88000810c3c0 R15: ffff88001d964000
FS:  00007f70c57fc780(0000) GS:ffffffff8155d100(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000000b145000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process Xorg (pid: 3005, threadinfo ffff88001dd9e000, task ffff880016408000)
Stack:  ffff88001d962000 ffff88001d964000 ffff88001dd9fe48 ffffffffa004405d
 ffffffffa007bb00 0000000000000000 ffff88001dd9fea8 ffffffffa0011d1d
 ffff880001014500 ffff880001014500 0000000000000000 ffff88001d96402c
Call Trace:
 [<ffffffffa004405d>] radeon_cp_resume+0x94/0xd7 [radeon]
 [<ffffffffa0011d1d>] drm_ioctl+0x1d6/0x25e [drm]
 [<ffffffffa0043fc9>] ? radeon_cp_resume+0x0/0xd7 [radeon]
 [<ffffffff810cb79b>] vfs_ioctl+0x5f/0x78
 [<ffffffff810cba01>] do_vfs_ioctl+0x24d/0x26a
 [<ffffffff810cba73>] sys_ioctl+0x55/0x7a
 [<ffffffff8101024a>] system_call_fastpath+0x16/0x1b

Code: 18 48 05 5c 01 00 00 89 38 8b 43 40 31 d2 48 89 df 8d 70 ff 03 73 3c c1 e8
 10 66 31 f6 09 c6 e8 21 e6 ff ff 48 8b 83 00 01 00 00 <48> 8b 00 89 c2 49 8b 84
 24 a0 03 00 00 03 53 40 2b 50 78 eb 1a 
RIP  [<ffffffffa0041e5b>] radeon_cp_init_ring_buffer+0x234/0x521 [radeon]
 RSP <ffff88001dd9fe18>
CR2: 0000000000000000
---[ end trace a8daf4a82d8bb065 ]---

Due to other bugs I am going to try some koji builds anyway.
Comment 12 Michal Jaegermann 2008-12-02 21:17:11 EST
With the current kernel and xorg-x11-drv-ati from koji (i.e. kernel-2.6.27.7-134.fc10 and xorg-x11-drv-ati-6.9.0-61.fc10) a crash from comment #11 does not happens anymore but user-switcher works only to that extent that it does open a new session.  Any attempt to get out of that new session by logging out or by switching to another session, graphic or a console, immediately crashes gdm and kills to what you want return.  gdm restarts but there is nowhere to switch back.
Comment 13 Ray Strode [halfline] 2008-12-03 09:36:06 EST
is there a backtrace of the gdm crash available in /var/log/messages ?
Comment 14 Michal Jaegermann 2008-12-03 10:33:50 EST
> is there a backtrace of the gdm crash ...

Maybe "crash" is not a good description.  It rather that /usr/libexec/gdm-simple-slave, and X and a desktop session with it, restart on its own while nobody asked.  The only thing I can find in dmesg and /var/log/messages is a series on entries of that sort:

agpgart-amd64 0000:00:00.0: AGP 3.5 bridge
agpgart-amd64 0000:00:00.0: putting AGP V3 device into 8x mode
pci 0000:01:00.0: putting AGP V3 device into 8x mode
[drm:radeon_do_init_cp] *ERROR* PCI GART memory not allocated!

I found that it is enough to try to switch to a text console.  The moment I attempt to go back the original desktop session is gone and I am staring at a new login window.

That is when "nomodeset" is in place.  If that is not used then I am bumping into another set of display nasties which are described in details in recent comments to bug #459285.

OTOH if I will boot _on the same machine_ the current rawhide installation
(that will be kernel-2.6.27.5-117.fc10.x86_64 at this moment) but where gdm
was replaced by a recompiled gdm-2.20.5-1 then I can switch between text
consoles and a graphic consoles until cows come home and running sessions stay put.  Still user-switcher is causing effects like those described in comment #11.

A reboot of my F10 installation with 2.6.27.5-117.fc10 allows me to switch
there and back between a graphic and text sessions without impunity (i.e.
gdm stays put).  An attempt with user-switcher locked a machine to that extent
that it is not accessible in any way.  That with 
xorg-x11-drv-ati-6.9.0-61.fc10 from koji I was asked to install in comments to
bug 459285.

Add to that font issues described in bug 466369 and things are skidding downhill pretty fast.
Comment 15 Michal Jaegermann 2008-12-03 20:50:54 EST
Just seen that: http://lkml.org/lkml/2008/12/3/535.
I do not have a "smoking gun" but to me it also looks that xorg-x11-drv-ati
changes are really responsible for a slew of problems.  I do not think that this has bearings on the original issue, which can be worked around eventually, but all kinds of nasty "side effects" prevent getting clean answers.

I put a similar note in bug 459285 too.
Comment 16 Bug Zapper 2009-11-18 03:07:09 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Bug Zapper 2009-12-18 00:52:42 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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