Hi there-
Ever since I switched from KDE 3.5 (F8) to KDE 4.2 (F10) I have this problem:
When:
* starting a KDE application, for instance konqueror * opening the start menu * attempting to add a new event in korganizer
What happens: (example: new konqui instance)
Konqueror appears. By default for me it appears in a blank window. However when trying to input anything in the location bar it does not take any input. In fact, it does not even redraw itself if I minimize it and then restore. It remains frozen like this for about 20 seconds. Then everything is normal again.
Once that happens everything is fine for a while (10 minutes or so). New konqueror windows come up and are responsive just fine. But if I don't do anything for a while the problem reappears.
What happens: (example: new event in korganizer)
I double-click on a time in korganizer. A "New Event" window comes up. Similar to the konqueror example, it draws itself completely, but then becomes nonresponsive and does not redraw itself. Becomes responsive again after about 20 seconds.
What happens: (example: start menu)
I click on the start menu. It appears as a black square with rounded corners, obscuring the desktop and windows underneath. In other words, different from the examples above it does not draw itself before freezing. It unfreezes after 20 seconds.
Speculation:
Some service is failing and KDE takes 20 seconds to notice that or to try and start it.
How do I debug that? I attached an strace log, but that is very opaque. Scroll down the timestamps and you see the big jump at 07:50:38.674661 and at 07:50:49.615261. Two select() calls that take 10 and 15 seconds, respectively. I guess file descriptor 7 is its connection to DBUS?
Any help would be appreciated. This is very frustrating.....
Cheers
Hans
How do I debug that? I attached an strace log, but that is very opaque.
It is too large it seems. Sorry about that. Here is a link instead:
On Tuesday 31 March 2009 18:12:34 Hans Ecke wrote:
Hi there-
Ever since I switched from KDE 3.5 (F8) to KDE 4.2 (F10) I have this problem:
When:
- starting a KDE application, for instance konqueror
- opening the start menu
- attempting to add a new event in korganizer
What is your graphics cards and what driver do you use for it?
Hans Ecke wrote:
What is your graphics cards and what driver do you use for it?
GeForce 7600 GS, using proprietary nvidia driver.
On another machine I'm using GeForce 7800 GTX, same driver, with no problem.
FWIW, I seriously doubt its a graphics card issue. Or a hardware issue in general.
You'd be surprised.
Is desktop-effects or compositing enabled? Have you tried reproducing without nvidia driver and/or using vesa driver?
-- Rex
You'd be surprised.
I believe you have seen quite the variety by now :-)
Is desktop-effects or compositing enabled?
Neither. In fact, my xorg.conf says
Section "ServerFlags" Option "AIGLX" "off" EndSection Section "Extensions" Option "Composite" "Disable" EndSection
Have you tried reproducing without nvidia driver and/or using vesa driver?
Fair enough question. I now switched to "nv". I should have an answer in half an hour or so - the problem never takes longer to appear.
Thank you
Hans
Hans Ecke wrote:
Jose & Rex-
Is desktop-effects or compositing enabled? Have you tried reproducing without nvidia driver and/or using vesa driver?
Same thing happens with the "nv" driver. Compositing, AIGLX, desktop effects still disabled.
with nvidia fully uninstalled? (even no libs being present?)
Try vesa?
-- Rex
with nvidia fully uninstalled? (even no libs being present?)
Yes.
However the rest of the desktop works just fine while the new Konqueror window is unresponsive. I can for instance still write this email inside my mail program.
Humor me for a minute. If it were not a graphics card driver issue, how would I figure out what Konqueror is trying to do for that select() call? What service is behind file descriptor 7?
Hi,
However the rest of the desktop works just fine while the new Konqueror window is unresponsive. I can for instance still write this email inside my mail program.
Humor me for a minute. If it were not a graphics card driver issue, how would I figure out what Konqueror is trying to do for that select() call? What service is behind file descriptor 7?
I also don't think its a graphic driver issue - usually many self-made-professionals point to that, without any real indication. If you use nv and the problem persists, it has nothing to do with the proprietary nvidia driver, period.
You could install debug symbols, and post some pstack outputs - that could give a clue whats going on there...
- Clemens
Clemens Eisserer wrote:
I also don't think its a graphic driver issue - usually many self-made-professionals point to that, without any real indication. If you use nv and the problem persists, it has nothing to do with the proprietary nvidia driver, period.
There's well-founded experience behind our seemingly crazy requests to reproduce bugs free of nvidia's taint (all files, libs, even nv's own libGL, etc...). I once found it hard to believe too, until I witnessed it (pauses/freezes in particular). NVidia's drivers are freaky beasts, and has caused countless episodes of wasted debugging. More than a few times, folk *swore* to me that their systems were nvidia-driver free... and guess what, they weren't, and when purged completely, wierdness disappeared.
I (we) really need to document this all on the wiki somewhere, so I don't need to re-write this rant every few weeks.
Back to the issue at hand, we'd all be happy to lend more efforts in helping diagnose this problem, really. But we can't afford to waste time on anything that can even remotely be attributed to nvidia-driver issues. Not me anyway, no thanks.
-- Rex
On Wednesday 01 April 2009 14:49:15 Rex Dieter wrote:
Clemens Eisserer wrote:
I also don't think its a graphic driver issue - usually many self-made-professionals point to that, without any real indication. If you use nv and the problem persists, it has nothing to do with the proprietary nvidia driver, period.
There's well-founded experience behind our seemingly crazy requests to reproduce bugs free of nvidia's taint (all files, libs, even nv's own libGL, etc...). I once found it hard to believe too, until I witnessed it (pauses/freezes in particular). NVidia's drivers are freaky beasts, and has caused countless episodes of wasted debugging. More than a few times, folk *swore* to me that their systems were nvidia-driver free... and guess what, they weren't, and when purged completely, wierdness disappeared.
I (we) really need to document this all on the wiki somewhere, so I don't need to re-write this rant every few weeks.
Why not write up a section on http://userbase.kde.org/Troubleshooting?
Anne
On 31/03/2009, Hans Ecke hans@ruelle.mines.edu wrote:
with nvidia fully uninstalled? (even no libs being present?)
Yes.
I dont know how you installed the nvidia drivers but are you aware that if you use the nvidia provided installer it replaces certain libraries on the system including libGL so simply uninstalling it or changing to another driver is *NOT* enough to remove it. If on the other hand you installed from rpmfusion you can yum remove the nvidia packages and then we can rule out nvidia proprietry drivers once and for all for this issue.
On Tuesday 31 March 2009 18:57:18 Hans Ecke wrote:
FWIW, I seriously doubt its a graphics card issue. Or a hardware issue in general.
Sure the problem is not the graphics card the problem is the driver. I had experience with similar cards and I had the same problems. The solution was to follow some hints given on userbase (http://userbase.kde.org/).
FWIW it was not one of my machines but one where my advice was requested and the only indication from me as "no nvidia, please". For several reasons the only option was a machine with the nvidia card and as I feared problems like that appeared. :-(
Believe me the culprit is the proprietary driver. The interface to pass options to the driver is awkward, sometimes it almost looks like they have tried their best to do their worse. :-)
Hans Ecke wrote:
Some service is failing and KDE takes 20 seconds to notice that or to try and start it.
How do I debug that? I attached an strace log, but that is very opaque. Scroll down the timestamps and you see the big jump at 07:50:38.674661 and at 07:50:49.615261. Two select() calls that take 10 and 15 seconds, respectively. I guess file descriptor 7 is its connection to DBUS?
I'm sorry, I fail to see any strace.log here. ??
One other thing that may be relevant is khotkeys (global shortcuts). I've heard of it causing symptoms like this.
Could try renaming/removing ~/.kde/share/config/kglobalshortcutsrc
and relogin.
Another thing to try is to see if this is reproducible as another (new) user on the same box. (rules out configuration issue).
-- Rex
Rex Dieter wrote:
Hans Ecke wrote:
Some service is failing and KDE takes 20 seconds to notice that or to try and start it.
How do I debug that? I attached an strace log, but that is very opaque. Scroll down the timestamps and you see the big jump at 07:50:38.674661 and at 07:50:49.615261. Two select() calls that take 10 and 15 seconds, respectively. I guess file descriptor 7 is its connection to DBUS?
I'm sorry, I fail to see any strace.log here. ??
One other thing that may be relevant is khotkeys (global shortcuts). I've heard of it causing symptoms like this.
Could try renaming/removing ~/.kde/share/config/kglobalshortcutsrc
and relogin.
Another thing to try is to see if this is reproducible as another (new) user on the same box. (rules out configuration issue).
Oh, another troublemaker is PackageKit-qt-0.3.15-1.fc10 that landed in updates-testing yesterday. It was inadvertantly built against qt-4.5.0, and causes keyboard related issues (another wierd one) for folks with only qt-4.4.x installed.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=493003
PackageKit-0.3.15-2.fc10 is better.
-- Rex
Rex & everybody-
I'm sorry, I fail to see any strace.log here. ??
http://mesoscopic.mines.edu/~hans/konqui.trace.15447
... but anyway: I solved it. This is a weird one, and I don't know if _anybody_ on the whole world will encounter the same problem. But I'll document it here anyway. I had a lot of fun tracking :-)
I first did a "ulimit -c unlimited" and then started konqueror on the command line with "--nocrashhandler --sync".
When konqueror became unresponsive, I killed it from another shell with "kill -7" which forced it to dump core.
The I ran gdb with that core file. A really cool feature: gdb now tells you what debuginfo packages to install to get all symbols. yum-utils contains the program debuginfo-install which will install them, even if no debuginfo repositories are enabled.
The backtrace inside gdb tells me that konqueror was inside an X11 core fonts (old font system!) request. That one is interesting. I did not know that qt still uses legacy fonts.
I'm still using the X Font Server xfs for fonts. Mostly because of inertia - always used it, has a tuned config, continue using it. But xfs dies for me. On some fonts from xorg-x11-fonts-100dpi. Strange. The problem is reproducible with "xlsfonts -l". So konqueror times out in its attempt to talk with xfs.
And some other background process (upstart?) kept restarting xfs every 15 minutes because it found it dead. So my system still limped along with an intermittently available xfs.
At this point I ran out of tuits. No fixing xfs. Instead I just disabled xfs, instead using the buitin FontPaths catalogue /etc/X11/fontpath.d. Now everything works fine. Bye old friend.
Question: I keep hearing about debuging KDE applications with kdebugdialog and related utilities. However that is a compile-time switch. In other words, everything has to be recompiled in order to use that functionality. Is there a way to make it available to us simple mortals without having to recompile all of KDE ourselves? Maybe a repository that contains fedora-kde compiled in debug mode? Or how much of a performance impact would it be to have it switched on in production builds?
Cheers
Hans
Hans Ecke wrote: ...
I'm still using the X Font Server xfs for fonts. Mostly because of inertia - always used it, has a tuned config, continue using it. But xfs dies for me. On some fonts from xorg-x11-fonts-100dpi. Strange. The problem is reproducible with "xlsfonts -l". So konqueror times out in its attempt to talk with xfs.
And some other background process (upstart?) kept restarting xfs every 15 minutes because it found it dead. So my system still limped along with an intermittently available xfs.
At this point I ran out of tuits. No fixing xfs. Instead I just disabled xfs, instead using the buitin FontPaths catalogue /etc/X11/fontpath.d. Now everything works fine. Bye old friend.
:) Impressive detective-work, please forgive my nvidia-related doubts.
I recall having various issues with xfs dying too back in the f8 days, and it was never resolved... my perception being that upstream and our maintainers didn't care all that much about it anymore (legacy, deprecated stuff often gets that kind of treatment sadly).
Anyway, I too will give a few moments of silence (say ~ 20 seconds) for the passing of our common old xfs comrade. Rest in peace, friend.
-- Rex
-
Anne Wilson -
Clemens Eisserer -
Hans Ecke -
John5342 -
José Abílio Matos -
Rex Dieter