Konqueror pushing CPU to 100%
Running SUSE 10.0 (retail). I updated to KDE 3.5 (from apt) and now whenever I start Konqueror, it pushes my CPU to 100%, and it stays there. Starting/stoppign Konq at this point is fast, but CPU load is stuck at 100% If I exit Konqueror, the CPU load stays at 100% until I kill the Konq process. Top shows that teh Konq process is the cuplrit... Anyone else experiencing this? Any suggestions for a way to track down the problem and fix it? C.
[Clayton]
Running SUSE 10.0 (retail). I updated to KDE 3.5 (from apt) and now whenever I start Konqueror, it pushes my CPU to 100%, and it stays there. [...] Anyone else experiencing this? Any suggestions for a way to track down the problem and fix it?
I got a problem which looks a bit similar, yet I would guess it is a different one. SuSE 10.0 is now very satisfactory for me. But on my initial tries, it was consuming all the CPU soon after graphical login, and it took me a few visits (rebooting SuSE 9.2 in the meantime for the necessities of real work) before I figured out where the problem was. Strangely, whenever the `xterm' program in UTF-8 mode (either using the `-u8' option, or having UTF-8 as part of the LANG environment variable), X goes wild and trashes (responds more and more slowly), consuming all the available CPU. Killing `xterm' recovers the usual X pace. This is repeatable at will here. I wonder if others could reproduce this problem. I'm using the YOU-downloaded NVidia driver, if it matters. My solution was first to use `mlterm' instead of `xterm', but I did not quickly find out how to select the font I wanted. So, I recompiled and installed `rxvt-unicode' from source, and all is perfect since I use it. -- François Pinard http://pinard.progiciels-bpi.ca
François Pinard wrote:
[Clayton]
Running SUSE 10.0 (retail). I updated to KDE 3.5 (from apt) and now whenever I start Konqueror, it pushes my CPU to 100%, and it stays there. [...] Anyone else experiencing this? Any suggestions for a way to track down the problem and fix it?
I got a problem which looks a bit similar, yet I would guess it is a different one. SuSE 10.0 is now very satisfactory for me. But on my initial tries, it was consuming all the CPU soon after graphical login, and it took me a few visits (rebooting SuSE 9.2 in the meantime for the necessities of real work) before I figured out where the problem was.
Strangely, whenever the `xterm' program in UTF-8 mode (either using the `-u8' option, or having UTF-8 as part of the LANG environment variable), X goes wild and trashes (responds more and more slowly), consuming all the available CPU. Killing `xterm' recovers the usual X pace. This is repeatable at will here. I wonder if others could reproduce this problem. I'm using the YOU-downloaded NVidia driver, if it matters.
My solution was first to use `mlterm' instead of `xterm', but I did not quickly find out how to select the font I wanted. So, I recompiled and installed `rxvt-unicode' from source, and all is perfect since I use it.
On x86_64, it's kded that's pushing to 99%. I've reported this to bugs.kde.org. A great site to view if you have KDE problems and the place to report bugs, account needs to be created in order to be able to report bugs. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, licensed Private Pilot Retired IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist Microsoft Windows Free Zone - Linux used for all Computing Tasks
On x86_64, it's kded that's pushing to 99%.
That happened to me too with the i386 version. I dropped back to KDE 3.43 and all is OK.
On my work computer I'm also getting the kded loading the CPU to 100%... on a 32 bit install, not 64 bit (even though it's running on an Athlon64). So on 2 different computers I have CPU load problems. On the home computer, Konqueror loads the CPU to 100% until I exit it and kill all instances of Konqueror. I discovered that if I change the Konqueror settings so that it does NOT keep Konq running in the background that when I exit any Konq I have open, it returns CPU load to zero. On my second computer - the one with kded causing problems - I killed the kded process and CPU load returned to zero. So far, no problems have cropped up from killing the kded process. Strange that on 2 virtually identical installs, I get the same problem, but with different apps. C.
Clayton, On Monday 24 October 2005 00:08, Clayton wrote:
On x86_64, it's kded that's pushing to 99%.
That happened to me too with the i386 version. I dropped back to KDE 3.43 and all is OK.
...
On my second computer - the one with kded causing problems - I killed the kded process and CPU load returned to zero. So far, no problems have cropped up from killing the kded process.
...
This is kind of a war mentality, isn't it? If you don't recognize something, kill it? As I understand it, and that understanding is minimal, kded is an integral and essential part of KDE. I cannot imagine that killing it is truly innocuous. Has it occurred to anyone that what kded is doing is not erroneous? For example, on my system when Kat's indexer runs, it uses kded to invoke some of its translation modules. When it does that, ps and top show kded consuming a lot of CPU, but it's not a problem. How long have you waited for this symptom to subside? One think you might want to do to diagnose this symptom is use lsof on kded to see which ".so" (shared object) files it has open. This might tell you which, if any, module it's executing. Something like this: % lsof -p $(pidof kded) |egrep '\.so$' \ |egrep -v ' /lib/' \ |sed -e 's;.* /;/;' At the moment on my system, there are 29 such files open by kded. Their names are fairly well indicative of their functions: /opt/kde3/lib/kde3/kded.so /opt/kde3/lib/libkdeinit_kded.so /opt/kde3/lib/kde3/plugins/styles/plastik.so /opt/kde3/lib/kde3/kded_kmilod.so /opt/kde3/lib/kde3/kmilo_generic.so /opt/kde3/lib/kde3/kmilo_kvaio.so /opt/kde3/lib/kde3/kmilo_thinkpad.so /opt/kde3/lib/kde3/kded_kdeprintd.so /opt/kde3/lib/kde3/kimg_ico.so /opt/kde3/lib/kde3/kmilo_delli8k.so /opt/kde3/lib/kde3/kded_systemdirnotify.so /opt/kde3/lib/kde3/kded_knemod.so /opt/kde3/lib/kde3/kded_katd.so /usr/lib/qt3/plugins/imageformats/libqjpeg.so /usr/lib/qt3/plugins/imageformats/libqmng.so /opt/kde3/lib/kde3/kded_kdetrayproxy.so /opt/kde3/lib/kde3/kded_kwrited.so /opt/kde3/lib/kde3/kded_dnssdwatcher.so /opt/kde3/lib/kde3/kded_kmldonkeyd.so /opt/kde3/lib/kde3/kded_mediamanager.so /opt/kde3/lib/kde3/kded_remotedirnotify.so /opt/kde3/lib/kde3/kded_networkstatus.so /opt/kde3/lib/kde3/kded_kinetd.so /opt/kde3/lib/kde3/kded_kwalletd.so /opt/kde3/lib/kde3/kded_khotkeys.so /opt/kde3/lib/kde3/kded_kssld.so /opt/kde3/lib/kde3/kded_kpasswdserver.so /opt/kde3/lib/kde3/kded_favicons.so /opt/kde3/lib/kde3/kded_kcookiejar.so One thing I notice immediately is that some of my system tray icons have counterparts here (Nemo and Kat, e.g.).
C.
Randall Schulz
This is kind of a war mentality, isn't it? If you don't recognize something, kill it?
Errr... no. It's the name of the command you use (on the command
line) to stop a process... it's "kill -9 <pid>" or "killall -9
How long have you waited for this symptom to subside?
Hours.... and it stays at 100%.. my processor temp rises from a normal 39 to 40C to 58C... so it's definitely chewing away on something. But... I rolled back to KDE 3.4.3 and all is back to normal. Seems to be a problem with KDE 3.5 - my KDE3.5 got to the point today that on 2 separate machines it stpped working altogether before I had a chance to roll them back to 3.4.3... had to do it all from command line YAST :-P C.
Randall R Schulz wrote:
Clayton,
On Monday 24 October 2005 00:08, Clayton wrote:
On x86_64, it's kded that's pushing to 99%. That happened to me too with the i386 version. I dropped back to KDE 3.43 and all is OK. ...
On my second computer - the one with kded causing problems - I killed the kded process and CPU load returned to zero. So far, no problems have cropped up from killing the kded process.
...
This is kind of a war mentality, isn't it? If you don't recognize something, kill it?
As I understand it, and that understanding is minimal, kded is an integral and essential part of KDE. I cannot imagine that killing it is truly innocuous.
Has it occurred to anyone that what kded is doing is not erroneous? For example, on my system when Kat's indexer runs, it uses kded to invoke some of its translation modules. When it does that, ps and top show kded consuming a lot of CPU, but it's not a problem.
How long have you waited for this symptom to subside?
One think you might want to do to diagnose this symptom is use lsof on kded to see which ".so" (shared object) files it has open. This might tell you which, if any, module it's executing. Something like this:
% lsof -p $(pidof kded) |egrep '\.so$' \ |egrep -v ' /lib/' \ |sed -e 's;.* /;/;'
At the moment on my system, there are 29 such files open by kded. Their names are fairly well indicative of their functions:
After a reboot, kat is docked, but greyed out and kded is running at <1%. bugs.dke.org requested unloading the kded_katd.so module. No errors have been found in the logs, so my problem seems to be katd. http://bugs.kde.org/show_bug.cgi?id=114862. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, licensed Private Pilot Retired IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist Microsoft Windows Free Zone - Linux used for all Computing Tasks
[François Pinard]
Strangely, whenever the `xterm' program in UTF-8 mode (either using the `-u8' option, or having UTF-8 as part of the LANG environment variable), X goes wild and trashes (responds more and more slowly), consuming all the available CPU. Killing `xterm' recovers the usual X pace. This is repeatable at will here. I wonder if others could reproduce this problem. I'm using the YOU-downloaded NVidia driver, if it matters.
My solution was first to use `mlterm' instead of `xterm', but I did not quickly find out how to select the font I wanted. So, I recompiled and installed `rxvt-unicode' from source, and all is perfect since I use it.
[Sid Boyce]
On x86_64, it's kded that's pushing to 99%. I've reported this to bugs.kde.org. A great site to view if you have KDE problems and the place to report bugs, account needs to be created in order to be able to report bugs.
So, it has to be a different problem, as I do not run KDE here, and there is no such `kded' in the process table. -- François Pinard http://pinard.progiciels-bpi.ca
participants (5)
-
Clayton -
François Pinard -
Michael Nelson -
Randall R Schulz -
Sid Boyce