Red Hat Bugzilla – Bug 194558
gdm is not reusing the lowest available vt (at least with multiple servers)
Last modified: 2009-12-18 00:52:42 EST
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!
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.
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)
> 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?
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.
> 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.
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.
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
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!
Does the user-switcher applet work? ck-list-sessions should tell you which VTs the active sessions are running on.
> 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.
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.
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.
is there a backtrace of the gdm crash available in /var/log/messages ?
> 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.
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.
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
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.