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