Hi,
I'm frequently experiencing a problem with kdm-trinity (V3.5.12) appearing to time out on system start-up. The following two lines are put into my syslog when this happens:
kdm[1966]: X server startup timeout, terminating kdm[1966]: X server for display :0 can't be started, session disabled
This is an intermittant problem and doesn't happen every time I start my system (I'd guess it occurs about 50% of the time). When it does I'm left with just the basic console. However, all I need to do to get X up and running is to log in on the console and restart kdm-trinity.
The system is running Debian Squeeze on amd64 with an nVidia graphics card using the proprietary nVidia driver.
Curiously, I don't recall this happening when I first installed TDE V3.5.12, which was quite some time ago now and it only seems to have started occurring relatively recently.
Since I first installed Trinity V3.5.12 I have installed a number of Debian Squeeze updates but in addition to this I also tried upgrading to TDE V3.5.13 but then had to downgrade back to TDE V3.5.12 due to a couple of problems with V3.5.13.
As I didn't remove TDE V3.5.13 and all of its config files when I downgraded back to TDE V3.5.12 I imagine that it's possible that kdm-trinity V3.5.13 introduced some different configuration settings. Alternatively, there have been a couple of kernel updates during this period (I compile my own kernels from the Debian linux-source package and then need to recompile the nVidia driver to fit the new kernel. The kernel updates have all been minor point updates so the kernel configs have been unchanged over the period concerned) and this may be a factor. Fwiw, the syslog messages from kdm-trinity appear about 15 seconds after the nVidia module load message.
I've also had a look in the Xorg.log files and while there are no clear errors or warnings there are differences at the end of the logs between successful and unsuccessful start ups as shown below...
Unsuccessful startup:
(**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc105" (**) Option "xkb_layout" "gb" (II) Power Button: Close (II) UnloadModule: "evdev" (II) Power Button: Close (II) UnloadModule: "evdev" (II) AT Translated Set 2 keyboard: Close (II) UnloadModule: "evdev" (II) ImExPS/2 Generic Explorer Mouse: Close (II) UnloadModule: "evdev" (II) ACPI Virtual Keyboard Device: Close (II) UnloadModule: "evdev"
Successful startup:
(**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc105" (**) Option "xkb_layout" "gb" (II) Open ACPI successful (/var/run/acpid.socket) (II) Feb 15 11:52:58 NVIDIA(0): Setting mode "1920x1200+0+0" (II) Power Button: Device reopened after 1 attempts. (II) Power Button: Device reopened after 1 attempts. (II) AT Translated Set 2 keyboard: Device reopened after 1 attempts. (II) ImExPS/2 Generic Explorer Mouse: Device reopened after 1 attempts. (II) ACPI Virtual Keyboard Device: Device reopened after 1 attempts.
The extract from the unsuccessful start up clearly shows that some of the devices are being closed but I can't see any reasons why and, as I say, there are no errors or warnings: apart from some different time-stamps earlier on in the logs they are otherwise identical (according to KDiff3).
Any hints or tips would be appreciated.
Regards,
LeeE
On Feb 15, 2012 8:13 AM, "leee" leee@spatial.plus.com wrote:
Hi,
I'm frequently experiencing a problem with kdm-trinity (V3.5.12)
appearing to
time out on system start-up. The following two lines are put into my
syslog
when this happens:
kdm[1966]: X server startup timeout, terminating kdm[1966]: X server for display :0 can't be started, session disabled
This is an intermittant problem and doesn't happen every time I start my system (I'd guess it occurs about 50% of the time). When it does I'm left with just the basic console. However, all I need to do to get X up and running is to log in on the console and restart kdm-trinity.
The system is running Debian Squeeze on amd64 with an nVidia graphics card using the proprietary nVidia driver.
Curiously, I don't recall this happening when I first installed TDE
V3.5.12,
which was quite some time ago now and it only seems to have started
occurring
relatively recently.
Since I first installed Trinity V3.5.12 I have installed a number of
Debian
Squeeze updates but in addition to this I also tried upgrading to TDE
V3.5.13
but then had to downgrade back to TDE V3.5.12 due to a couple of problems with V3.5.13.
As I didn't remove TDE V3.5.13 and all of its config files when I
downgraded
back to TDE V3.5.12 I imagine that it's possible that kdm-trinity V3.5.13 introduced some different configuration settings. Alternatively, there
have
been a couple of kernel updates during this period (I compile my own
kernels
from the Debian linux-source package and then need to recompile the nVidia driver to fit the new kernel. The kernel updates have all been minor
point
updates so the kernel configs have been unchanged over the period
concerned)
and this may be a factor. Fwiw, the syslog messages from kdm-trinity
appear
about 15 seconds after the nVidia module load message.
I've also had a look in the Xorg.log files and while there are no clear
errors
or warnings there are differences at the end of the logs between
successful
and unsuccessful start ups as shown below...
Unsuccessful startup:
(**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc105" (**) Option "xkb_layout" "gb" (II) Power Button: Close (II) UnloadModule: "evdev" (II) Power Button: Close (II) UnloadModule: "evdev" (II) AT Translated Set 2 keyboard: Close (II) UnloadModule: "evdev" (II) ImExPS/2 Generic Explorer Mouse: Close (II) UnloadModule: "evdev" (II) ACPI Virtual Keyboard Device: Close (II) UnloadModule: "evdev"
Successful startup:
(**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc105" (**) Option "xkb_layout" "gb" (II) Open ACPI successful (/var/run/acpid.socket) (II) Feb 15 11:52:58 NVIDIA(0): Setting mode "1920x1200+0+0" (II) Power Button: Device reopened after 1 attempts. (II) Power Button: Device reopened after 1 attempts. (II) AT Translated Set 2 keyboard: Device reopened after 1 attempts. (II) ImExPS/2 Generic Explorer Mouse: Device reopened after 1 attempts. (II) ACPI Virtual Keyboard Device: Device reopened after 1 attempts.
The extract from the unsuccessful start up clearly shows that some of the devices are being closed but I can't see any reasons why and, as I say,
there
are no errors or warnings: apart from some different time-stamps earlier
on
in the logs they are otherwise identical (according to KDiff3).
Any hints or tips would be appreciated.
My first suggestion is to backup your ~/.trinity directory and do a purge your Trinity packages to get rid of any conflicting config files. From there you should be able to install a fresh 3.5.12 (the ~/.trinity should still be intact). If it still doesn't work, you can try purging/reinstalling Xorg (or try a different version of nvidia driver, though I remember it crashing a lot awhile back).
On Wednesday 15 February 2012 21:12:33 Kristopher Gamrat wrote: [snip...]
Any hints or tips would be appreciated.
My first suggestion is to backup your ~/.trinity directory and do a purge your Trinity packages to get rid of any conflicting config files. From there you should be able to install a fresh 3.5.12 (the ~/.trinity should still be intact). If it still doesn't work, you can try purging/reinstalling Xorg (or try a different version of nvidia driver, though I remember it crashing a lot awhile back).
Thanks for your suggestions but I don't think either will help.
'Conflicting' TDE configuration files won't be the reason, at least certainly not in my ~/ (home) folder - the problem is occurring when kdm-trinity starts (or doesn't) - this is before any home folders are examined, which will only happen once kdm-trinity _has_ started and allowed me to log in. There _may_ be a changed value in one of the /etc/trinity/kdm/ config files but after having a look at them I can't see anything obvious.
I'm afraid that purging Xorg isn't a viable option either. On a desktop/workstation system such as this I'd estimate that > 90% of all the packages installed have dependencies upon Xorg, whether directly or indirectly. If I was to purge Xorg I might as well just go for a complete re-install, which is something I've never had to do with Linux. Neither do I think that the nVidia driver is the problem (I'm using the latest driver) - I've been using them for years with no problems (unlike the ATI drivers - ATI seemed to be incapable of implementing OpenGL properly - dunno if they're any better now that AMD have taken them over though).
To be honest, I'm really beginning to think that the problem is not anything to do with kdm-trinity itself (the default timeout period of kdm-trinityis 15 seconds, which fits with what I'm seeing in the syslog, and which should be ample time anyway).
I'm now looking into two other possible areas: the cpu in this system has six cores @ 3.2GHz but I've noticed that during the initial stages of the boot only one of them is activated, which seems to activate the 'turbo-boost' feature which in turn up-clocks that core to 3.6GHz. The initial Linux kernel timing calculations seem to be using this 3.6GHz rating but once all six cores are activated the speed drops back down to 3.2GHz: this _might_ be resulting in timing errors within the kernel when it comes to load the nVidia module. The other possibility is that it might be because I haven't turned my wireless mouse on and 'woken up' the mouse interface.
I think I have to say that whilst uninstalling and re-installing may be the quickest way of solving problems on MS Windows this is rarely, if ever, the best way to fix problems on Linux. It doesn't identify the cause of the problem or tell you why the problem has been fixed (if it actually fixes the problem). Linux is much more deterministic when compared with MS Windows and when it says it has done something it actually means that it's done it, not just that it might have tried to do it.
Regards,
LeeE
On Wed, 15 Feb 2012 13:13:20 +0000 leee leee@spatial.plus.com wrote:
Hi,
I'm frequently experiencing a problem with kdm-trinity (V3.5.12) appearing to time out on system start-up. The following two lines are put into my syslog when this happens:
kdm[1966]: X server startup timeout, terminating kdm[1966]: X server for display :0 can't be started, session disabled
This is an intermittant problem and doesn't happen every time I start my system (I'd guess it occurs about 50% of the time). When it does I'm left with just the basic console. However, all I need to do to get X up and running is to log in on the console and restart kdm-trinity.
The system is running Debian Squeeze on amd64 with an nVidia graphics card using the proprietary nVidia driver.
A similar bug seems to be filed against KDM in several distros (usually it's against the KDE4 KDM, but I've found one mention that predates it). The recommended fix is to open up kdmrc and add a line like
ServerTimeout=120
to the [X-*-Core] section. I don't know whether or not Trinity will recognize that config option, but it might be worth trying.
On 02/16/2012 11:57 AM, E. Liddell wrote:
ServerTimeout=120
to the [X-*-Core] section. I don't know whether or not Trinity will recognize that config option, but it might be worth trying.
It should - there haven't been many changes to kdm. I load kdm from inittab and I don't have any issues with hangs or timeouts.
x:5:respawn:/opt/kde3/bin/kdm -nodaemon
On Thursday 16 February 2012 23:58:09 David C. Rankin wrote:
On 02/16/2012 11:57 AM, E. Liddell wrote:
ServerTimeout=120
to the [X-*-Core] section. I don't know whether or not Trinity will recognize that config option, but it might be worth trying.
It should - there haven't been many changes to kdm. I load kdm from inittab and I don't have any issues with hangs or timeouts.
x:5:respawn:/opt/kde3/bin/kdm -nodaemon
Thanks for both suggestions - I'll look into them. 120 seconds seems rather high though, so I'll probably start with lower values.
LeeE
-
David C. Rankin -
E. Liddell -
Kristopher Gamrat -
leee