When logging out, user is taken to VT1 instead of KDM on VT7. When restarting XDM from VT1, user is again taken to VT1 after filling in username and password pressing enter/clicking on login. The only way login works correctly is on a fresh boot. Reproducible: Always Steps to Reproduce: 1. Login as regular user 2. Logout 3. Restart xdm 4. Attempt to login Actual Results: User is returned to VT1 when attempting to login via KDM more than once after boot. Expected Results: Ability to log users in and out without being bounced to VT1. Please let me know what logs to attach to troubleshoot this issue. eix kdm (4.2.4 installed): [I] kde-base/kdm Available versions: (3.5) 3.5.9 3.5.10 (4.2) (~)4.2.4 {arts consolekit debug elibc_FreeBSD elibc_glibc handbook kdeenablefinal kdehiddenvisibility kdeprefix kerberos pam xinerama} Installed versions: 4.2.4(4.2)(10:26:31 07/09/09)(consolekit handbook pam -debug -kdeprefix -kerberos) Homepage: http://www.kde.org/ Description: KDE login manager, similar to xdm and gdm eix kdebase-startkde (4.2.4 installed): [I] kde-base/kdebase-startkde Available versions: (3.5) 3.5.9 3.5.10-r5 (4.2) (~)4.2.4 {arts debug elibc_FreeBSD kdeenablefinal kdeprefix xinerama} Installed versions: 4.2.4(4.2)(04:15:42 07/08/09)(-kdeprefix) Homepage: http://www.kde.org/ Description: Startkde script, which starts a complete KDE session, and associated scripts emerge --info: Portage 2.2_rc33 (default/linux/amd64/2008.0, gcc-4.3.3, glibc-2.10.1-r0, 2.6.29-tuxonice-r3 x86_64) ================================================================= System uname: Linux-2.6.29-tuxonice-r3-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T5250_@_1.50GHz-with-gentoo-2.0.1 Timestamp of tree: Sun, 19 Jul 2009 19:45:01 +0000 app-shells/bash: 4.0_p24 dev-java/java-config: 2.1.8-r1 dev-lang/python: 2.5.4-r2, 2.6.2-r1 dev-util/cmake: 2.6.4 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r3 sys-apps/sandbox: 2.0 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.29 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/conf.d/clock /etc/conf.d/hostname /etc/conf.d/hwclock /etc/conf.d/xdm /etc/hosts /etc/rc.conf /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/ http://gentoo.mirrors.tds.net/gentoo http://gentoo.netnitco.net http://mirror.datapipe.net/gentoo http://gentoo.mirrors.easynews.com/linux/gentoo/ http://gentoo.mirrors.hoobly.com/ http://chi-10g-1-mirror.fastsoft.net/pub/linux/gentoo/gentoo-distfiles/ http://www.cyberuse.com/gentoo/ " LDFLAGS="-Wl,-O1" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X acl acpi administrator alsa amd64 apache2 apm aspell audiofile berkdb bzip2 cdaudio cdb cdda cddb clamav clamd clamdtop cli consolekit cpudetection cracklib crypt ctype cups curl dbus dell directfb dragonplayer dri dvd dvdr embedded encode exif fam fbcon fbcondecor fbsplash ffmpeg flac fortran gd gdbm gif gimp gnokii google-gadgets gphoto2 gpm hal iconv id3tag imagemagick ipv6 isdnlog java jpeg jpeg2k kde kde4 lame laptop lcms midi mjpeg mmx mng mp3 mp3tunes msn mudflap multilib musepack musicbrainz mysql mysqli ncurses networkmanager nls nptl nptlonly nsplugin ogg openexr opengl openmp otr pam pcre pdf perl png ppds pppd python qt3 qt3support quicktime raw readline realmedia reflection rss ruby samba scanner schroedinger sensord session spell spl sse sse2 ssl startup-notification svg sysfs tcpd templates threads tiff truetype unicode usb vcd vorbis wav wavpack webkit winpopup wmf wmp xcf xorg xprint xscreensaver xulrunner yahoo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="intel" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I assume you have x11-base/xorg-server-1.6.2-r1 installed? If yes, I can confirm this problem. It happens with kdm-3.5.10, too. The only difference is that after logging out from the first (successfully started) session, kdm reappears but as soon as I type any key on the keyboard, kdm crashes and my system is switching to a VT. After executing "/etc/init.d/xdm restart" I can again sucessfully log into X once.
Yep. That's the version I have. So this is really an xorg-server bug, then?
I've talked to a dev in #gentoo-kde and he said it's a kdm-issue so I gonna reassign this bug to the kde-herd...
Sounds good. Thanks!
Could you post /var/log/Xorg.0.log and /var/log/kdm.log after logging out the first time and after restarting xdm (and kdm crashes again) please?
I have 2 machines this happens on. One is a laptop, the other a desktop. On the laptop, when I log out, I don't even get switched to a VT. The screen just goes blank and a cursor sticks to the upper left corner. All I can do is ctrl-alt-del as nothing else gets me anywhere. Attachments to follow.
Created attachment 198639 [details] Xorg.0.log for laptop (screen blanks, no VT upon logout)
Created attachment 198641 [details] KDM log from laptop (screen blanks, no VT upon logout)
Right... nix on the desktop I mentioned. It's not having any problems logging in and out between different users. So it's just the latop, for which I just added the log files. I hope they help.
Created attachment 198642 [details] xorg.0.log after i try to log out it seems like a intel problem to me. X crashes when i try to log out with or without kms. At least the log gives a clue.
Yes, this seems to be an xorg/intel issue, other users using intel and xorg 1.6.2 have reported the same problem as you in IRC. I can't reproduce it with nvidia. I'm going to rename this bug and assing it to x11.
This seems to happen every now and then. I'm pretty sure there are open bugs for this issue. (too tired to look, feel free to grok through bugzilla). You might want to file a bug upstream [1] so they can start to dig into this before the final 2.8 release. Please paste the url here once you've opened the bug report. Thanks [1] http://intellinuxgraphics.org/how_to_report_bug.html
No problem with intel card/driver. Happens with my nvidia card and x11-drivers/nvidia-drivers, too. I will attach my logfiles later.
Adding KDE herd, I doubt xorg-server is the only culprit here. Maybe kdm doesn't restart X properly or something. All I know is that on all my boxes (with intel, nvidia and ati cards), gdm is able to restart X. Here's to hoping we figure this one once and for all :) Thanks
(In reply to comment #14) > Adding KDE herd, I doubt xorg-server is the only culprit here. Maybe kdm > doesn't restart X properly or something. All I know is that on all my boxes > (with intel, nvidia and ati cards), gdm is able to restart X. Could be, but it works on my (kdm) boxes as well... We'll need more input from people actually experiencing this :) Maybe some of you can install gdm (or another, lighter login manager like x11-misc/slim) to see if the issue persists.
(In reply to comment #15) > Could be, but it works on my (kdm) boxes as well... > We'll need more input from people actually experiencing this :) Right, that'd be interesting. > Maybe some of you can install gdm (or another, lighter login manager like > x11-misc/slim) to see if the issue persists. Hum, slim is full of bugs, better not recommend it :) GDM is a good idea though, if KDE users are willing to (temporarily) pollute their systems with gnome libs ;) Here's something else : can anyone reproduce with startx? Thanks
Installed GDM and it logs in and out just fine. Renamed this bug back to "KDM" instead of "xorg-server", as the culprit does not appear to be xorg-server.
Reassigning then :) I'd still be interested in knowing what one does that the other doesn't do. Thanks
Please bear with me. I will attach my logfiles as soon as I have time to upgrade to xorg-server-1.6 again. Due to this error I am still using xorg-server-1.5.3...
Created attachment 198965 [details] Xorg.0.log
Created attachment 198966 [details] kdm.log Here are my logs as promised but I'm afraid they are of no real help.
xorg-server-1.6.3 still leads to crashes of kdm after logging out from X for the first time.
looks like https://bugs.freedesktop.org/show_bug.cgi?id=20516 That's all I can think of right now. Thanks
Yeah but the problem is not limited to graphics devices from intel. I can trigger this error on my machine with nvidia graphics device as well as in a virtualbox-vm.
Could you attach a gdb to X and/or kdm to get a backtrace when things crash? Thanks
I still wasn't able to get any useful backtraces of the bug. Whenever I try to run kdm from inside of gdb it simply exits with SIGUSR1 after it started the X server.
What about Xorg ?
*** Bug 283024 has been marked as a duplicate of this bug. ***
Created attachment 205085 [details] xorg 1.6.3.601-r2 + intel-2.8.1 back trace FWIW here's the log + backtrace of the current X11 suite (used keysword list from http://bugs.gentoo.org/282290)
@Toralf, Could you use layman to add the x11 overlay, and emerge xf86-video-intel-9999 in there? It should work with xorg-server 1.6. You might want to unmask libdrm-2.4.14 as well. Please let me know if you can still reproduce afterward. Thanks
(In reply to comment #30) > @Toralf, > > Could you use layman to add the x11 overlay, and emerge xf86-video-intel-9999 > in there? It should work with xorg-server 1.6. You might want to unmask > libdrm-2.4.14 as well. > > Please let me know if you can still reproduce afterward. > > Thanks > Hhm, layman seems not to work (make.conf changed wrt to "source ...") : n22 ~ # equery l -p xf86-video-intel-9999 [ Searching for package 'xf86-video-intel' in all categories among: ] * installed packages * Portage tree (/usr/portage) n22 ~ # ls -l /usr/local/portage/layman/x11/x11-drivers/xf86-video-intel/ total 8 -rw-r--r-- 1 root root 206 Sep 24 13:14 Manifest -rw-r--r-- 1 root root 815 Sep 24 13:14 xf86-video-intel-9999.ebuild
pls forget #comment 31, the emerged 9999 ebuild (commit a92bbcc) now doesn't crash X11- instead the whole (external) LCD is black however the mouse cursor is seen - but no error message within Xorg.0.log nor /var/log/messages - tested with kernel 2.6.31 and KMS enabled.
I'm sorry, but I'm lost :) Could you explain what the complete situation is like? Thanks
Removing kde for now, I'll add you guys back if kdm is somehow at fault. Thanks
That means, that after a logout from kdm X do not crash, however I cannot see a login prompt nor anything else then the mouse cursor.
Ok, and if you restart the X server completely? (ctrl-alt-backspace or /etc/init.d/xdm restart) Does everything go back to normal? Thanks
(In reply to comment #36) > Ok, and if you restart the X server completely? (ctrl-alt-backspace or > /etc/init.d/xdm restart) > > Does everything go back to normal? > > Thanks > yes - I added 'Option "XkbOptions" "terminate:ctrl_alt_bksp"' to xorg.conf, therefore both things works - it is "only" a nagging issue and furthermore b/c I use external displays (w/ a different size), a restart of X11 resets the resolution, therefore I have to use xrandr again to set x*y size and dpi ...
Ok so it looks like xorg-server's regen bugs still aren't completely fixed. @kde, this is indeed an X bug (I'm now 99.99% sure of it). The cause of this bug is that kdm doesn't kill the server like gdm does, but somehow uses the "regen" feature to do a soft relaunch. Is there a way to tell kdm to kill the server like gdm does until this issue is properly fixed upstream? Thanks
(In reply to comment #38) > Is there a way to tell kdm to kill the server like gdm does until this issue is > properly fixed upstream? Add this line 'TerminateServer=true' to /usr/kde/3.5/share/config/kdm/kdmrc
(In reply to comment #39) > (In reply to comment #38) > > Is there a way to tell kdm to kill the server like gdm does until this issue is > > properly fixed upstream? > Add this line 'TerminateServer=true' to /usr/kde/3.5/share/config/kdm/kdmrc Thank you very much for this hint. This works for kdm4 as well (/usr/share/config/kdm/kdmrc). So I can finally switch to xorg-server-1.6 :)
*** Bug 287458 has been marked as a duplicate of this bug. ***
Seems like this has already been reported upstream: https://bugs.freedesktop.org/show_bug.cgi?id=21831 If anyone wants to comment on that bug please keep in mind that this problem is not limited to xf86-video-intel driver as I can perfectly reproduce it on my nvidia card with kdm-3 as long as I don't use the "fix" provided by Toralf in comment #39
Issue solved w/ x11-drivers/xf86-video-intel-2.9.1 (and x11-base/xorg-server-1.6.4)
(In reply to comment #43) > Issue solved w/ x11-drivers/xf86-video-intel-2.9.1 (and > x11-base/xorg-server-1.6.4) > Updating vanilla kernel 2.6.31.5 to .6 brought it back again - however now I can see (for 2 seconds) the login screen before it will become black ...
I have the same problem on my system and uncommenting "TerminateServer=true" in /usr/share/config/kdm/kdmrc worked around the problem. For reference, my system is a Lenovo T61 with an integrated graphics controller (Intel 965GM) running amd64 (x86_64) w/ KDE 4.3.1. The following is also reported via syslog: kdm[11212]: X server for display :0 terminated unexpectedly I originally found the workaround on a Debian bug(1), which mentions a KDE bug(2), before finding this Gentoo bug. (1) http://bugs.debian.org/541272 (2) http://bugs.kde.org/202629
(In reply to comment #44) > Updating vanilla kernel 2.6.31.5 to .6 brought it back again - however now I > can see (for 2 seconds) the login screen before it will become black ... > The issue does not happen with vanilla 2.6.31.6, xorg 1.6.4, xf86-input-evdev-2.2.5, if after logout from kdm I - either wait 10 seconds, until I hear a short access to the hard disk and after that I can type in my password - or if I type in only the first 2 characters of my password and wait then 10 seconds before I can continue to type, sometimes however the 2 already typed in characters are deleted.
It's probably worth putting the explanation here: Since time immemorial the MIT(etc) X server has auto-restarted when all clients disconnect - it tries to do pretty much of an exec(itself) to completely reset its own state. This was always the default - you have to say "-terminate" to the X server to get it to exit (ever). xdm and related display managers (like kdm) rely on this - they expect not to need to restart the server after every session. Here's what kdm runs on my machine: /usr/bin/X -br -novtswitch -quiet -nolisten tcp :0 vt7 -auth /var/run/xauth/xxxx Ok, that's fine, but if the X server *crashes* then the DM has to start it again (obviously), and if the DM fails to do this then that is a BUG in the DM. It isn't possible to manually restart the X server (so far as I can see), in particular "/etc/init.d/xdm restart" kills *all* the X sessions attached to the machine (including those on independent heads and on remote X terminals); not a good idea ;-) Normally kdm *does* restart the server. I can send the server SEGV during regular sessions or while the login window is up and kdm nicely restarts it. *But*, on my system, the X server SEGVs inside the driver shutdown and then, for some reason, can't be immediately restarted, so I see: May 08 08:51:14 [kdm] X server for display :0 terminated unexpectedly May 08 08:51:14 [kdm] Unable to fire up local display :0; disabling. Ok, it's a bug probably in a driver, but kdm needs to handle this better (e.g. try again in a few seconds - do a back-off). KDE seem to be in denial about this: http://bugs.kde.org/202629 I'll update that bug, but I suggest it be patched in gentoo too (e.g. by adding the appropriate configuration to get -terminate on the server options - I can't work out how to do this; I can't even find a kdm config file.)
The kdm config file can be found at /usr/share/config/kdm/kdmrc
See the KDE bug for the fix - it's not a driver bug, it's a bug in the X org 'xdm' code (dm.c) which has been copied wholesale into kdm. I'll probably have a gentoo patch in a while - I have a fix on gentoo/kdm in a bit.
Created attachment 230829 [details, diff] Patch to fix this bug by fixing xdm problems contained in kdm. Attached is a patch for kdm-4.3.5, I tested it against 'r1' (since r2 is masked), it fixes my problems. It should fix any problem where the X server terminates after a reset is initiated and before the xdm XOpenDisplay completes. It changes the magic timeout to 20s and makes it so that for local X servers the timeout is from the time of the server start, not the session start. It doesn't change XDCMP sesssions (and I verified I can still Xming to the patched system.) This patch is specific to the xdm (X-Consortium, or whatever it is today) code - it's not kdm specific and may need to be applied to other DMs.
Here's the xorg bug that I just entered: https://bugs.freedesktop.org/show_bug.cgi?id=28034
So, is this still a problem with kdm-4.4.4?
(In reply to comment #52) > So, is this still a problem with kdm-4.4.4? I haven't tried 4.4.4 (because I switched over to using xdm), however the KDE bug has shown no activity since May 13 when Oswald Buddenhagen said "I'll come up with a fix." You could just resolve it 'upstream', but it's annoying and widely reported so I think it is worth patching in gentoo even though the KDM maintainer doesn't like the patch.
I'll port your patch to 4.4.4 we have in tree, as for upstream, I'll wait for ossi before doing any magling in 4.4 branch. Just for record, it happens when using nvidia drivers as well.
This patch (albeit probably fixing some timeout issues) doesn't solve issues with screen going black on logout, therefore it's probably X regen bug (it certainly appeared here with xorg-server upgrade, I can assure about it as it happened earlier in my ~arch chroot as well) and needs to be worked around with TerminateServer=true
(In reply to comment #55) You need to look in *syslog* (where ever it is on your system). If you see: May 08 08:51:14 [kdm] X server for display :0 terminated unexpectedly May 08 08:51:14 [kdm] Unable to fire up local display :0; disabling. (Or something like this) then it is this bug and can be worked round by killall -1 kdm (to cause kdm to reenable the X server.) My patch should fix it. Neither Xorg.log nor kdm.log will help here. If my patch doesn't work (and the server still gets disabled) then I'd like to know exact times for the original successful server session (start and end) and the disable message. (The patch relies on the whole thing taking more than 30s.) If the X server is still running, or if kdm did not disable it, then it's some other bug. Note that a hang on a server restart will probably produce an identical looking problem but kdm may not be able to handle it (e.g. if the server locks out the VT.)
My (and not just my) nvidia issue is different, whole screen goes blank and is frozen completely (only SysRq: SAK helps - that's definitely driver bug and/or incompatibility with new Xserver as it used to work with 1.6). Your patch doesn't help here. TerminateServer=true does help however, unless... you do 'Switch User', log-on and then log him off - this causes hard freeze again. I suggest the following. I'll apply your patch *and* set TerminateServer=true, so that majority have working setup. Now, those unaffected by hard freezes are free to coment out TerminateServer=true in their kdmrc (and make use of X regen with kdm fixed by yourself).
Fixed in 4.4.4-r1, please test.
(In reply to comment #57) > My (and not just my) nvidia issue is different, whole screen goes blank and is > frozen completely Please confirm that in *your* case kdm is not logging a 'disabled' message in syslog and/or that the X server is still running when VT7 is blank. You can simple switch to VT1, log in an run ps ax | egrep X to find out if the server is running, and the 'disabled' message will be in your syslog (it depends on your syslogd where that is.) (If something is wrong with VT1 you can ssh in, etc.)
So can we resolve this one?
Ok - it's *definitely* upstream. The 'terminateserver=true' change is not a fix - it's a work-round: http://bugs.kde.org/show_bug.cgi?id=202629#c19 As of today my repro case is fixed, but that's because there was a bug in X11 server reset when using a fontserver (at least a TCP font server) that caused the server to crash on reset and *that* is fixed. Different bug, but I can no longer repo as a result on KDE 4.4.5. I do not know, and it is extremely difficult for me to find out (ok, I didn't trawl the code), whether 4.4.5 contains the upstream fix: it is necessary to have a separate, X11 server crash-on-restart, bug to repro the bug in kdm. I tried the fast login/logout repro (less than maybe 20s between sessions might disable the display) and kdm seemed fine, but I don't even know for sure that the fast login/logout could reliably repro the bug. There *was* (and maybe *is*) a bug in kdm: this bug. The fact that it requires another bug to repro doesn't stop it from being a bug (much as large numbers of software engineers would like to believe that their own code only has to work if everyone else's does ;-) KDE bug 202629 (http://bugs.kde.org/202629) is dead in the water, so I'm fairly confident that Oswald is a software engineer (despite his comments in May). The net result on that was that I was wrong about the bug being upstream of kdm (xorg) and Oswald rebuked me for bothering xorg when I should have been bothering him. So as things stand the bug is firmly with Oswald and KDM: http://bugs.kde.org/show_bug.cgi?id=202629#c19 Despite the Bugzilla engineer honey trap of offering me the opportunity to resolve this 'upstream' I can't do so. Only a sufficiently 'empowered' user can do this, I suggest that one of the empowered does so.
resolving per last comment
