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