>> Need help here folks to file a good
>> bug report.
>>
>> I have been using TDE in a virtual machine. Yesterday I
>> created some partitions on a spare hard drive and installed
>> TDE so I could start using and testing on a physical
>> machine.
>>
>> I can't start TDE.
>>
>> I think I traced the problem to a conflict between
>> kdetcompmgr and the proprietary Nvidia drivers, but I'm not
>> sure.
>>
>> I say that because that is where my xession log shows the
>> startkde script stalls.
>>
>> When I switch to the vesa driver (which looks awful on a
>> wide screen monitor :)) I am able to start TDE with no
>> problems. I can migrate an existing KDE3 profile or start
>> empty and let TDE create a new profile. Either way TDE
>> starts with no stalls.
>>
>> After the TDE profile exists, whether new or migrated, I
>> can return to the Nvidia drivers and TDE will start with no
>> stalling.
>>
>> When I have the Nvidia drivers selected and no TDE profile
>> yet exists, I am able to start TDE under only one bizarre
>> circumstance:
>>
>> Toggle to a console and run "killall kconf_update." I have
>> to do that twice during the TDE startup. Doesn't matter
>> whether I am starting TDE with a migrated KDE3 profile or am
>> letting TDE create a new profile. The splash image won't
>> appear until I execute the first killall. The startup stalls
>> with the splash image at "Initializing system services"
>> until I run the second killall.
>>
>> When TDE stalls like this, the kconf_update process takes
>> control of my system. The system bogs down and my CPU ramps
>> to full speed and the CPU temperature rises quickly.
>>
>> I don't see anything in the startkde script that directly
>> calls kconf_update. What is calling that command?
>>
>> Slackware 13.1, starting X from the console (startx
>> command). Dual core AMD 2.3 GHz, 4GB RAM.
>>
>> Any ideas?
>
> Additional information:
>
> I moved the spare drive to an older computer that uses the tdfx video
> driver rather than Nvidia. No problems starting TDE, with or without a
> migrated KDE3 profile.
>
> Further, I can modify the startkde script to run the kdetcompmgr command
> in the background. That eliminates the need for first killall. I can't
> figure out how to avoid needing the second killall when the splash screen
> is at the "Initializing system services" point.
>
> At this point I'm reasonably sure there is a conflict with the Nvidia
> drivers.
>
> After a TDE profile exists the problem disappears. The problem occurs only
> with the first use of startkde, with either migrating a KDE3 profile or
> creating a new profile.
>
> At this point I don't know what is keying off of what to trigger
> kconf_update to run.
>
> Darrell
>

I haven't seen this behaviour in ages!  It is an nVidia issue, as they
replace a system library (actually several of them) with nVidia-specific
versions.  For some reason, those replaced libraries don't work 100% with
the kinit system.  To prove this, fire up gdb and attach to the frozen
process.  When you generate a backtrace, you will see nVidia binary blobs
at the most recent call depth, even though kinit obviously does not
compile/link against nVidia.

Tim