Two Birds with One Stone!

I had this problem with KDM while I was using amd64 on this Sempron64 machine. KDM would work fine for a while and then would become very slow on startup. By slow, I mean nearly 20 seconds. The NVIDIA logo would show up, followed by a blank screen with a busy mouse pointer in the middle. Normally, this screen would last only for a couple of seconds and KDM would show up. But here, it would keep showing for all of those 20 seconds. After that KDM would appear. During the blank screen period, there would a lot of disk activity.

The problem was very irritating. But I never bothered to solve it on that system.

I replaced the amd64 system with x86 last month. KDM had been fine till the start of this week. Then came the same problem. 20 seconds to start up. Very frustating. Today, I actually went on about investigating it. So here's how it went.

First of all, I needed to check the 'span' of the problem. I had had an X server crash today (Beryl and NVIDIA beta.. "Shit happens" ;-)). I noticed that after the crash, KDM started up normally, in no time at all. I logged out and the same thing happened. It started up normally. So apparently, the problem was only with the initial startup.

I next checked if KDM was the last thing starting on bootup, just to make sure that it isn't some other init script that starts up after KDM that causes this. After a few changes using rc-update and a reboot or two, I managed to conclude that the problem was with KDM itself.

Next, I removed xdm from the runlevel. Logged in as root and tried to run xdm. No go. No X and this in Xorg.0.log:

(II) Loader running on linux
(II) LoadModule: "bitmap"
(WW) Warning, couldn't open module bitmap
(II) UnloadModule: "bitmap"
(EE) Failed to load module "bitmap" (module does not exist, 0)
(II) LoadModule: "pcidata"
(WW) Warning, couldn't open module pcidata
(II) UnloadModule: "pcidata"
(EE) Failed to load module "pcidata" (module does not exist, 0)

Fatal server error:
Unable to load required base modules, Exiting...

(WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor
(WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor

Ok. That didn't actually come as a surprise. I was unable to start that init script manually on the amd64 system either. X wouldn't start, syslog saying that VT7 was not available. I had ignored this too, back then. Well, I decided to fix it today.

I don't know why, but I opened up /etc/conf.d/xdm file. I didn't even know it existed before this. I found this in the file:

# Tell X to always start on VT7. Otherwise it autodetects the first available
# VT, which means it has to wait until all gettys are started so it doesn't suck
# up a VT that should have had a login prompt (very slow).
# If XSTATICVT is on, the login manager will start as soon as possible during
# the boot process. If you want X to dynamically start on the first unoccupied
# VT after all gettys have started and you are using xdm, also remove the "vt7"
# from /etc/X11/xdm/Xservers.
XSTATICVT="yes"

I changed XSTATICVT to no and issued a /etc/init.d/xdm start and behold! X started up fine. But, again, KDM took a lifetime to start.

This time though, I was already logged in on tty1. I switched to it and ran top while KDM was in that blank screen phase. I could see kdm_greet eating away at the CPU all the while the blank screen was displayed. I stopped the xdm init script and launched it again. KDM startup was normal this time. So the culprit was found. kdm_greet did something on the first startup that it didn't have to do on the subsequent startups..

Here's the solution that popped up: http://www.mail-archive.com/debian-qt-kde%40lists.debian.org/msg10087.html

Nice (!). A simple fc-cache -sv and a reboot and I could see the problem solved! The title of this post justified!

You know, its nice to play Sherlock Holmes sometimes.

Btw, big thanks to SimAtWork in #kde for helping me with the KDM issue. He/she was the one that gave me the link to the solution. :-D