Konqueror is slow when opening a directory

Bug #64325 reported by Alexander Berger
8
Affects Status Importance Assigned to Milestone
kdebase (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: konqueror

When clicking on a directory icon from within konqueror it freezes for about 10 seconds while very slowly showing the visual effect for the click. Then the directory's content is shown correctly.

If I enter an new URL or path in the location bar konqueror immediately opens the directory without freezing. I have created a detailed log file using linux's strace utility and my findings are that konqueror spends its time talking to the X11-Server when it freezes. Filedescriptor 3 is a unix domain socket connected to the X11-Server (see below).

socket(PF_FILE, SOCK_STREAM, 0) = 3
uname({sys="Linux", node="gizmo", ...}) = 0
uname({sys="Linux", node="gizmo", ...}) = 0
connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 19) = 0
uname({sys="Linux", node="gizmo", ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC)
...

When clicking on a directory icon, konqueror freezes for about 10 seconds spending its time with the following calls:

...
open("/lib64/.directory", O_RDONLY) = -1 ENOENT (No such file or directory)
ioctl(3, FIONREAD, [0]) = 0
write(3, "5\30\4\0b\5\200\1]\0\0\0000\0000\0H\2\6\tb\5\200\1\16\0"..., 14392) = 14392
write(3, ";\3\5\0\253\1\200\1\0\0\0\0\264\0\234\0\225\1\212\0\230"..., 1984) = 1984
ioctl(3, FIONREAD, [0]) = 0
ioctl(3, FIONREAD, [0]) = 0
select(24, [3 4 5 8 10 18 19 20 21 22 23], [], [], {0, 0}) = 0 (Timeout)
ioctl(3, FIONREAD, [0]) = 0
select(24, [3 4 5 8 10 18 19 20 21 22 23], [], [], {0, 11293}) = 1 (in [3], left {0, 4000})
ioctl(3, FIONREAD, [32]) = 0
read(3, "\5\1\27674A\37\35]\0\0\0e\4\200\1\0\0\0\0\266\1n\1\267"..., 32) = 32
write(3, "&\3\2\0]\0\0\0", 8) = 8
read(3, "\1\1\2777\0\0\0\0]\0\0\0\235P \1\266\1n\1\266\1n\1\0\0"..., 32) = 32
ioctl(5, FIONREAD, [0]) = 0
write(7, "\0", 1) = 1
ioctl(5, FIONREAD, [1]) = 0
write(3, ";\3\5\0\253\1\200\1\0\0\0\0\233\0V\0004\0G\0\230\6\5\0"..., 712) = 712
write(3, "8\3\4\0\253\1\200\1\0\0\10\0\0\0\0\0:\0\4\0*\2\200\1\0"..., 76) = 76
nanosleep({0, 5000000}, NULL) = 0
write(3, "C\3\7\0e\4\200\1*\2\200\1\262\0m\0\4\0\4\0\257\0j\0\t\0"..., 28) = 28
nanosleep({0, 5000000}, NULL) = 0
write(3, "C\3\7\0e\4\200\1*\2\200\1\257\0j\0\t\0\t\0\255\0h\0\16"..., 28) = 28
nanosleep({0, 5000000}, NULL) = 0
write(3, "C\3\7\0e\4\200\1*\2\200\1\255\0h\0\16\0\16\0\252\0e\0\23"..., 28) = 28
nanosleep({0, 5000000}, NULL) = 0
write(3, "C\3\7\0e\4\200\1*\2\200\1\252\0e\0\23\0\23\0\250\0c\0\30"..., 28) = 28
nanosleep({0, 5000000}, NULL) = 0
write(3, "C\3\7\0e\4\200\1*\2\200\1\250\0c\0\30\0\30\0\245\0`\0\35"..., 28) = 28
nanosleep({0, 5000000}, NULL) = 0
write(3, "C\3\7\0e\4\200\1*\2\200\1\245\0`\0\35\0\35\0\243\0^\0\""..., 28) = 28
nanosleep({0, 5000000}, NULL) = 0
write(3, "C\3\7\0e\4\200\1*\2\200\1\243\0^\0\"\0\"\0\240\0[\0\'\0"..., 28) = 28
nanosleep({0, 5000000}, NULL) = 0
write(3, "C\3\7\0e\4\200\1*\2\200\1\240\0[\0\'\0\'\0\236\0Y\0,\0"..., 28) = 28
nanosleep({0, 5000000}, NULL) = 0
access("/lib64", R_OK) = 0
...

Then the opened directory is shown as expected. There are no messages on
STDOUT, STDERR or any of the kde or X11 log channels/files.
I suspect that the problem is the visual effect after the click on a directory icon, but I am not an expert at all.

Konqueror is quite unusable that way.

--- My System configuration ---
Dell XPS M1210 Notebook
Kubuntu 6.10 Beta Edgy Eft (with latest updates as of today)
CPU: intel core 2 duo (64bit mode)
X11-Driver: i810 (intel 946GM graphics card)

Tags: acpi kernel
Revision history for this message
Christian Schürer-Waldheim (quincunx) wrote :

Hi,
I have exactly the same problem on my notebook - it doesn't only effect konqueror but kdesktop too (probably kdesktop just uses konqueror libraries).

Sometimes (some of the first clicks) it might work - but most of the times it takes 10 seconds and more to open an link (links in general, not only directory links!).

For me, the desktop isn't usable this way.

My system configuration:
Dell Latitude D620
Kubuntu 6.10 Beta Edgy Eft (with latest updates)
CPU: intel core 2 duo - 64bit mode
X11-driver: nv (nVidia Quadro 110)

Revision history for this message
Christian Schürer-Waldheim (quincunx) wrote :

It seems as if we are the only one having this problem :-(

Interestingly, installing the 2.6.15-kernel from dapper solves this problem with konqueror, but I'm still having Bug #39315: Keyboard random repeat and dropped key presses

2.6.15-23-amd64-generic #1 SMP PREEMPT Tue May 23 13:45:47 UTC 2006 x86_64 GNU/Linux

Could you try if 2.6.15-23 kernel of dapper solves the konqueror problem for you too?

Revision history for this message
Christian Schürer-Waldheim (quincunx) wrote :

If you use the kernel boot parameters "noapic" and/or "acpi=noirq", then this problem should be gone - but then you will only have one cpu core (if you have a dual core cpu like me - an Intel Core 2 Duo).

Please give some feedback if this solves the problem for you, thanks!

Revision history for this message
Alexander Berger (alex-berger) wrote :

Well, actually I am using ubuntu edgy which uses kernel 2.6.17.10.
2.6.17-10-generic #2 SMP Fri Oct 13 15:34:39 UTC 2006 x86_64 GNU/Linux

Using acpi=noirq the problem is gone but my second core is also gone that way. As I will not miss the full power of my core 2 duo system. This is not a valid fix to me, but it might be a hint to the cause of the problem.

Revision history for this message
Christian Schürer-Waldheim (quincunx) wrote :

Something within the kernel must have changed crucial, so that other applications show strange behaviour.

The only kernel which works best for me now (regarding this bug and bug# 39315) is the 2.6.15-kernel from dapper: 2.6.15-23-amd64-generic #1 SMP PREEMPT Tue May 23 13:45:47 UTC 2006 x86_64 GNU/Linux

I've even compiled kernel 2.6.18 and 2.6.19rc2-mm2 myself (optimised for Intel Core 2 Duo) - but the problems described in both bug reports aren't solved with any of them.

Additionally, I have disabled the boot splash screen (it causes a lot of problems regarding the keyboard issue) and I'm using the kernel option pci=assign-busses.

I can't estimate whether this is an kernel- or an application-based (X or KDE) bug. Neither do I know what has changed from the kernel side from 2.6.15 to 2.6.17, so that this all happens.

Revision history for this message
Christian Schürer-Waldheim (quincunx) wrote :

This problem seems to be solved with the kernel which is in Ubuntu feisty (published today)

2.6.19-4-generic #2 SMP Wed Nov 1 00:18:29 UTC 2006 x86_64 GNU/Linux

Revision history for this message
Kevin Cantu (kevincantu-deactivatedaccount) wrote :

This does look related to #39315, and may be fixed eventually. Just thought I'd chime in that I'm seeing this on a Core 2 Duo, Dell E1405.

Ubuntu Edgy / 2.6.17-10-generic / x86_64

Revision history for this message
Pablo Di Noto (pablo-dinoto) wrote :

Something similar happens with my Lenovo 3000 N100 (typecode 0689-a32) which has a Celeron-M.

I use Kubuntu 6.10, using stock 2.6.17-11-generic or 2.6.20 built with make-kpkg on the system.

It is not the very same problem, but the closest match I have found.

In my case, konqueror freezes for up to 1m. Sometimes when typing the 1st letter in the address bar (most common way to reproduce), but there are others: Fresh Konqueror window, click on home dir, then 1-2m freeze. In some cases desktop responds to window switching, in other cases the entire desktop is unresponsive. Mouse always works. VT switch to tty0 works also work. Switching back to VT7 brings the desktop (it is redrawn), but still locked. Apps keep running (like Amarok keeps playing music).

Of course, this machine has no problem in Windows. Not tried any other Linux distro yet.

Will try the noapic and apci=noirq and report.

Revision history for this message
FeuerFrei (trej03) wrote :

I think the problem lies within a TSC compatibility problem with multi-core processors with independant core clocking. it seems that frequency scaling is improperly registered by the kernel, and causes bugs such as this one and bug 99356 with some keyboards. To solve it, just add "notsc" to your boot kernel parameters, or compile a kernel without the TSC components

Revision history for this message
Kieran Hogg (xerosis) wrote :

Christian said that Feisty solved these issues, is that the same for you Alexander?

Changed in kdebase:
status: New → Incomplete
Revision history for this message
Alexander Berger (alex-berger) wrote :

Yes I can confirm that, with Feisty the problems seems to be solved.

Revision history for this message
Kieran Hogg (xerosis) wrote :

Thanks, marking as fixed.

Changed in kdebase:
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.