By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 688

Summary: TDE won't start the first time with Nvidia proprietary drivers installed
Product: TDE Reporter: Darrell <darrella>
Component: tdebaseAssignee: Timothy Pearson <kb9vqf>
Status: RESOLVED WORKSFORME    
Severity: normal CC: bugwatch, darrella
Priority: P1    
Version: R14.0.0 [Trinity]   
Hardware: Other   
OS: Other   
Compiler Version: TDE Version String:
Application Version: Application Name:

Description Darrell 2011-11-25 19:59:33 CST 
The first time TDE is run the startup process hangs. The splash image never appears. The startkde script output to my xsession log stops at the point where kdetcompmgr is run.

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.

There is no escape from this process. Exiting TDE and restarting starts the charade all over.

Waiting for 15 minutes makes no difference.

When I switch to the vesa driver 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 then can return to the Nvidia drivers and TDE will start with no stalling.

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.

I have 3.5.10 running as well as 3.5.13 (dual boot). I don't have this problem in 3.5.10 with the Nvidia drivers installed.

Nvidia version 195.36.31. Same version used on 3.5.10.

Asking people to temporarily restore the stock X libs or disable the Nvidia drivers is not a doable solution for most people.
Comment 1 Timothy Pearson 2011-11-25 20:02:38 CST 
A backtrace will be required as mentioned on the mailing list.

Also, regression testing across KDE 3.5.10, TDE 3.5.11, TDE 3.5.12, and 3.5.13 would help.  The bug lies within kdelibs or Qt3.

Tim
Comment 2 Darrell 2011-11-30 17:48:23 CST 
More notes.

The problem definitely is kconf_update.

When I boot into the command line rather than X, I can run kconf_update and thereafter start X without stalling. If X is running when kconf_update is invoked, then kconf_ stalls.

I can't duplicate the problem using the vesa drivers. Only the proprietary Nvidia drivers.

Attaching to the kconf_update process reveals nothing:

============================
Attaching to the kconf_update process:

No stack.
Attaching to process 23912

blah, blah...

0xb5dcb236 in ?? () from /usr/lib/libGL.so.1
#0  0xb5dcb236 in ?? () from /usr/lib/libGL.so.1
============================

Backtrace of kdetcompmgr:

============================
Attaching to the kdetcompmgr process:

#0  0xb6a946ce in __waitpid_nocancel () from /lib/libc.so.6
#1  0xb75fd222 in my_system () at /dev/shm/kdelibs/kdecore/kapplication.cpp:1049
#2  KApplication::startKdeinit () at /dev/shm/kdelibs/kdecore/kapplication.cpp:1459
#3  0xb75fd77d in KApplication::dcopFailure (this=0xbfabf1fc, msg=...) at /dev/shm/kdelibs/kdecore/kapplication.cpp:1471
#4  0xb7605022 in KApplication::qt_invoke (this=0xbfabf1fc, _id=16, _o=0xbfabe800)
    at /dev/shm/kdelibs.build/kdecore/kapplication.moc:279
#5  0xb7088de5 in QObject::activate_signal(QConnectionList*, QUObject*) () from /opt/trinity/lib/libqt-mt.so.3
#6  0xb708b11f in QObject::activate_signal(int, QString) () from /opt/trinity/lib/libqt-mt.so.3
#7  0xb75289d3 in DCOPClient::attachFailed (this=0x8091570, t0=...) at /dev/shm/kdelibs.build/dcop/dcopclient.moc:149
#8  0xb7531e5f in DCOPClient::attachInternal (this=0x8091570, registerAsAnonymous=false)
    at /dev/shm/kdelibs/dcop/dcopclient.cpp:782
#9  0xb753154b in DCOPClient::registerAs (this=0x8091570, appId=..., addPID=true) at /dev/shm/kdelibs/dcop/dcopclient.cpp:967
#10 0xb75f9afd in KApplication::dcopAutoRegistration (this=0xbfabf1fc) at /dev/shm/kdelibs/kdecore/kapplication.cpp:1099
#11 0xb760af1d in KApplication::init (this=0xbfabf1fc, GUIenabled=true) at /dev/shm/kdelibs/kdecore/kapplication.cpp:899
#12 0xb760fd1a in KApplication (this=0xbfabf1fc, allowStyles=true, GUIenabled=false)
    at /dev/shm/kdelibs/kdecore/kapplication.cpp:667
#13 0x080493ff in main (argc=1, argv=0xbfabf474) at /dev/shm/kdelibs/kdecore/kdetcompmgr.cpp:52
============================
Comment 3 Darrell 2011-12-23 23:32:41 CST 
An update: kconf_update is related to the problems experienced in bug report 760. More than likely there is a relationship.
Comment 4 Darrell 2013-04-23 11:11:20 CDT 
I am closing this report. I haven't seen this behavior in a long while. I also did a lot of starting TDE with no previous profile when testing the migratekde3 script and did not see this happen. There have been many improvements since this report was filed, along with extensive renaming, and many nvidia updates. Who knows what might have resolved the problem.