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?
Darrell
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
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
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.
Ah, confirmation. :)
I don't know how to attach to the frozen process or generate a backtrace. Probably should learn. :)
I don't think I need to do any of that to confirm what I already see. I know that the proprietary Nvidia drivers replace a few files. The question is how do I/we work around that?
I have 3.5.10 running here as well as 3.5.13. I don't have this problem in 3.5.10 with the Nvidia drivers installed.
Asking people to temporarily restore the stock X libs or disable the Nvidia drivers will cause people to laugh and forget about testing or using TDE. That is not a doable solution for newbies who are interested in TDE.
1. Is there any damage in startkde of running kdetcompmgr as a background task?
2. What process started in startkde is launching kconf_update?
3. Why is kconf_update being launched?
4. Is there a way to prevent kconf_update from running?
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.
Ah, confirmation. :)
I don't know how to attach to the frozen process or generate a backtrace. Probably should learn. :)
I don't think I need to do any of that to confirm what I already see. I know that the proprietary Nvidia drivers replace a few files. The question is how do I/we work around that?
I have 3.5.10 running here as well as 3.5.13. I don't have this problem in 3.5.10 with the Nvidia drivers installed.
Asking people to temporarily restore the stock X libs or disable the Nvidia drivers will cause people to laugh and forget about testing or using TDE. That is not a doable solution for newbies who are interested in TDE.
- Is there any damage in startkde of running kdetcompmgr as a background
task?
What process started in startkde is launching kconf_update?
Why is kconf_update being launched?
Is there a way to prevent kconf_update from running?
Darrell
What version of the nVidia drivers does Slackware install?
The issue occurs within a very low level section of code, and I have not seen it on my Ubuntu systems in ages, thus I suspect it may be a known issue with older versions of the nVidia driver.
Tim
- Is there any damage in startkde of running
kdetcompmgr as a background
task?
- What process started in startkde is launching
kconf_update?
Why is kconf_update being launched?
Is there a way to prevent kconf_update from
running?
What version of the nVidia drivers does Slackware install?
The issue occurs within a very low level section of code, and I have not seen it on my Ubuntu systems in ages, thus I suspect it may be a known issue with older versions of the nVidia driver.
Slackware does not install any Nvidia packages. They are left to the users to build and install.
I am using 195.36.31 and have been for a long time. That is what I'm using on 3.5.10 too, where I don't see this behavior.
Is changing the Nvidia package the answer? Many people are going to be attracted to TDE because of the potential to run on older hardware. If those people have older Nvidia cards they will be using legacy drivers.
Darrell
- Is there any damage in startkde of running
kdetcompmgr as a background
task?
- What process started in startkde is launching
kconf_update?
Why is kconf_update being launched?
Is there a way to prevent kconf_update from
running?
What version of the nVidia drivers does Slackware install?
The issue occurs within a very low level section of code, and I have not seen it on my Ubuntu systems in ages, thus I suspect it may be a known issue with older versions of the nVidia driver.
Slackware does not install any Nvidia packages. They are left to the users to build and install.
I am using 195.36.31 and have been for a long time. That is what I'm using on 3.5.10 too, where I don't see this behavior.
Is changing the Nvidia package the answer? Many people are going to be attracted to TDE because of the potential to run on older hardware. If those people have older Nvidia cards they will be using legacy drivers.
Darrell
I don't know. This particular bug would require a LOT of time to troubleshoot and I don't have that much time to offer for free at this point.
If anyone else wants to take a stab at it feel free!
Tim
- Is there any damage
in startkde of running
kdetcompmgr as a background
task?
- What process started in startkde is
launching
kconf_update?
Why is kconf_update being launched?
Is there a way to prevent kconf_update
from
running?
What version of the nVidia drivers does Slackware
install?
The issue occurs within a very low level section
of code,
and I have not seen it on my Ubuntu systems in ages, thus I
suspect it may
be a known issue with older versions of the nVidia driver.
Slackware does not install any Nvidia packages. They
are left to the users
to build and install.
I am using 195.36.31 and have been for a long time.
That is what I'm using
on 3.5.10 too, where I don't see this behavior.
Is changing the Nvidia package the answer? Many people
are going to be
attracted to TDE because of the potential to run on
older hardware. If
those people have older Nvidia cards they will be
using legacy drivers.
I don't know. This particular bug would require a LOT of time to troubleshoot and I don't have that much time to offer for free at this point.
If anyone else wants to take a stab at it feel free!
Let's not focus yet on the bowels of the kdeinit code. Let's focus on the four questions I posed:
1. Is there any damage in startkde of running kdetcompmgr as a background task?
2. What process started in startkde is launching kconf_update?
3. Why is kconf_update being launched?
4. Is there a way to prevent kconf_update from running?
If I can throw a few snippets into the startkde script that will suffice for now.
As I mentioned, I can avoid the need for one of the killall commands if I run kdetcompmgr as a background task in startkde. I am unable to avoid the second killall command but there might be a workaround if I better understood why kconf_update is being launched and by what.
Apparently kconf_update is not being run in the same manner after the TDE profile is created because the stalls no longer occur. If I knew what to set in the new or migrated profile then I might be able to stop the stalls.
Darrell
- Is there any damage
in startkde of running
kdetcompmgr as a background
task?
- What process started in startkde is
launching
kconf_update?
Why is kconf_update being launched?
Is there a way to prevent kconf_update
from
running?
What version of the nVidia drivers does Slackware
install?
The issue occurs within a very low level section
of code,
and I have not seen it on my Ubuntu systems in ages, thus I
suspect it may
be a known issue with older versions of the nVidia driver.
Slackware does not install any Nvidia packages. They
are left to the users
to build and install.
I am using 195.36.31 and have been for a long time.
That is what I'm using
on 3.5.10 too, where I don't see this behavior.
Is changing the Nvidia package the answer? Many people
are going to be
attracted to TDE because of the potential to run on
older hardware. If
those people have older Nvidia cards they will be
using legacy drivers.
I don't know. This particular bug would require a LOT of time to troubleshoot and I don't have that much time to offer for free at this point.
If anyone else wants to take a stab at it feel free!
Let's not focus yet on the bowels of the kdeinit code. Let's focus on the four questions I posed:
- Is there any damage in startkde of running kdetcompmgr as a background
task?
Yes
- What process started in startkde is launching kconf_update?
Don't know
- Why is kconf_update being launched?
To regenerate a configuration file index IIRC
- Is there a way to prevent kconf_update from running?
Not a good idea
Sorry!
Tim
- Is there any damage in startkde of running
kdetcompmgr as a background
task?
Yes
- What process started in startkde is launching
kconf_update?
Don't know
- Why is kconf_update being launched?
To regenerate a configuration file index IIRC
- Is there a way to prevent kconf_update from
running?
Not a good idea
Sorry!
Looks like kded might be causing this. There is a setting in KControl KDE Performance to disable system configuration startup checks. Possibly that can be enabled to stop kconf_update.
Darrell
- Is there any damage in startkde of running
kdetcompmgr as a background
task?
Yes
- What process started in startkde is launching
kconf_update?
Don't know
- Why is kconf_update being launched?
To regenerate a configuration file index IIRC
- Is there a way to prevent kconf_update from
running?
Not a good idea
Sorry!
Looks like kded might be causing this. There is a setting in KControl KDE Performance to disable system configuration startup checks. Possibly that can be enabled to stop kconf_update.
Darrell
I would suggest filing a bug report on this. Mark the priority to minor, as this seems to only affect a small number of systems that have a third-party binary blob installed.
We will need a stack trace from gdb attached to the bug report. Best way to do that is: 1.) Wait for the process to hang 2.) Switch to another console and find the PID of the hung process 3.) Start gdb with 'gdb' 4.) Issue these commands to gdb: a.) attach <PID you found above> b.) bt
gdb should now spit out a backtrace that can be attached to the bug report. You will of course need the debugging symbols installed for the backtrace to be of any use. ;-)
Tim
Looks like kded might be causing this. There is a
setting in KControl KDE
Performance to disable system configuration startup
checks. Possibly that
can be enabled to stop kconf_update.
I would suggest filing a bug report on this. Mark the priority to minor, as this seems to only affect a small number of systems that have a third-party binary blob installed.
We will need a stack trace from gdb attached to the bug report. Best way to do that is: 1.) Wait for the process to hang 2.) Switch to another console and find the PID of the hung process 3.) Start gdb with 'gdb' 4.) Issue these commands to gdb: a.) attach <PID you found above> b.) bt
gdb should now spit out a backtrace that can be attached to the bug report. You will of course need the debugging symbols installed for the backtrace to be of any use. ;-)
I'm using the same packages I made available to everybody else: no debugging support. So I'll have to rebuild every package to get this. Well I guess at least kdelibs and kdebase.
The DelayCheck feature had no effect.
The only thing that works is configure X with vesa, start TDE, exit, and then restore Nvidia.
Darrell
Looks like kded might be causing this. There is a
setting in KControl KDE
Performance to disable system configuration startup
checks. Possibly that
can be enabled to stop kconf_update.
I would suggest filing a bug report on this. Mark the priority to minor, as this seems to only affect a small number of systems that have a third-party binary blob installed.
We will need a stack trace from gdb attached to the bug report. Best way to do that is: 1.) Wait for the process to hang 2.) Switch to another console and find the PID of the hung process 3.) Start gdb with 'gdb' 4.) Issue these commands to gdb: a.) attach <PID you found above> b.) bt
gdb should now spit out a backtrace that can be attached to the bug report. You will of course need the debugging symbols installed for the backtrace to be of any use. ;-)
I'm using the same packages I made available to everybody else: no debugging support. So I'll have to rebuild every package to get this. Well I guess at least kdelibs and kdebase.
The DelayCheck feature had no effect.
The only thing that works is configure X with vesa, start TDE, exit, and then restore Nvidia.
Darrell
You should be fine with just the debugging symbols for kdelibs.
Tim
We will need a stack trace from gdb attached to the bug report. Best way to do that is: 1.) Wait for the process to hang 2.) Switch to another console and find the PID of the hung process 3.) Start gdb with 'gdb' 4.) Issue these commands to gdb: a.) attach <PID you found above> b.) bt
gdb should now spit out a backtrace that can be attached to the bug report. You will of course need the debugging symbols installed for the backtrace to be of any use. ;-)
I don't know if I doing all of this correctly. I have two back traces. I don't know whether they are useful. I'll post them here because they are small. If they look useful then I'll attach them to the bug report.
============================ 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 ============================
============================ 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 ============================
Anything obvious?
More observations, both using the nvidia proprietary drivers:
When I disable kdetcompmgr in startkde, I eliminate the first requirement to run killall kconf_update.
When I add the --no-kded parameter to the start_kdeinit_wrapper command in startkde, I eliminate the second killall.
Lastly, KPersonalizer seems to launch kdetcompmgr, even after I disable kdetcompmgr in startkde.
Darrell
On Friday 25 November 2011 05:27:34 pm Timothy Pearson wrote:
- Is there any damage in startkde of running
kdetcompmgr as a background
task?
- What process started in startkde is launching
kconf_update?
Why is kconf_update being launched?
Is there a way to prevent kconf_update from
running?
What version of the nVidia drivers does Slackware install?
The issue occurs within a very low level section of code, and I have not seen it on my Ubuntu systems in ages, thus I suspect it may be a known issue with older versions of the nVidia driver.
Slackware does not install any Nvidia packages. They are left to the users to build and install.
I am using 195.36.31 and have been for a long time. That is what I'm using on 3.5.10 too, where I don't see this behavior.
Is changing the Nvidia package the answer? Many people are going to be attracted to TDE because of the potential to run on older hardware. If those people have older Nvidia cards they will be using legacy drivers.
Darrell
I don't know. This particular bug would require a LOT of time to troubleshoot and I don't have that much time to offer for free at this point.
If anyone else wants to take a stab at it feel free!
If it works with the 2D FOSS 'nv' driver, we can suggest that to new users. Not much exists in Linux that requires 3D capabilities, so unless new users truly need that, nv should work until this is sorted out.
Unfortunately, I don't have any nvidia cards (I try to avoid them because of their drivers), so I can't test with any other version of the driver.
If it works with the 2D FOSS 'nv' driver, we can suggest that to new users. Not much exists in Linux that requires 3D capabilities, so unless new users truly need that, nv should work until this is sorted out.
Unfortunately, I don't have any nvidia cards (I try to avoid them because of their drivers), so I can't test with any other version of the driver.
Unfortunately nv has been broken for a long time. There is no support for wide screen monitors. Been there done that. :)
The nouveau driver is not available in most distros of recent past. Available in the latest and all bleeding edge distros but not those from a year or two ago. We can't ignore those distros. And there remain more than a few bugs with the nouveau driver.
Darrell
-
Darrell Anderson -
Kristopher John Gamrat -
Timothy Pearson