25 Nov
2011
25 Nov
'11
8:37 a.m.
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
25 Nov
25 Nov
11:45 a.m.
New subject: [trinity-devel] Unable to start TDE
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
12:12 p.m.
New subject: [trinity-devel] Unable to start TDE
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
1:10 p.m.
New subject: [trinity-devel] Unable to start TDE
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
1:25 p.m.
New subject: [trinity-devel] Unable to start TDE
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
2:18 p.m.
New subject: [trinity-devel] Unable to start 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?
2:27 p.m.
New subject: [trinity-devel] Unable to start 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?
2:36 p.m.
New subject: [trinity-devel] Unable to start 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?
> >
> What version of the nVidia drivers does Slackware
install?
> 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 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.
2:38 p.m.
New subject: [trinity-devel] Unable to start 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?
> >
> What version of the nVidia drivers does Slackware
install?
> 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 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.
2. What process started in startkde is launching kconf_update?
Don't know
3. Why is kconf_update being launched?
To regenerate a configuration file index IIRC
4. Is there a way to prevent kconf_update from running?
Not a good idea
Sorry!
Tim
2:41 p.m.
New subject: [trinity-devel] Unable to start TDE
On Friday 25 November 2011 05:27:34 pm Timothy Pearson wrote:
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.
--
Kristopher Gamrat
Ark Linux webmaster
http://www.arklinux.org/
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?
2:53 p.m.
New subject: [trinity-devel] Unable to start TDE
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
3:53 p.m.
New subject: [trinity-devel] Unable to start TDE
1. Is there
any damage in startkde of running
kdetcompmgr as a background
task?
Yes
2. What process started in startkde is launching
kconf_update?
Don't know
3. Why is kconf_update being launched?
To regenerate a configuration file index IIRC
4. Is there a way to prevent kconf_update from
running?
Not a good idea
Sorry!
4 p.m.
New subject: [trinity-devel] Unable to start TDE
1. Is there any damage in startkde of running
kdetcompmgr as a background
task?
Yes
2. What process started in startkde is launching
kconf_update?
Don't know
3. Why is kconf_update being launched?
To regenerate a configuration file index IIRC
4. Is there a way to prevent kconf_update from
running?
Not a good idea
Sorry!
5:22 p.m.
New subject: [trinity-devel] Unable to start TDE
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. ;-)
5:34 p.m.
New subject: [trinity-devel] Unable to start TDE
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. ;-)
27 Nov
27 Nov
4:58 p.m.
New subject: [trinity-devel] Unable to start TDE
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
4554
days inactive
4557
days old
15 comments
3 participants
participants (3)
-
Darrell Anderson -
Kristopher John Gamrat -
Timothy Pearson