https://bugs.kde.org/show_bug.cgi?id=430241
Bug ID: 430241
Summary: Dolphin takes a very long time to tart
Product: dolphin
Version: 20.08.2
Platform: Kubuntu Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: dolphin-bugs-n...@kde.org
Reporter: r...@chewies.net
CC: kfm-de...@kde.org
Target Milestone: ---
Created attachment 133986
--> https://bugs.kde.org/attachment.cgi?id=133986&action=edit
strace with timestamps
SUMMARY
When opening dolphin on raspberry pi 4 on ubuntu 20.10, dolphin takes
excessively long (4-5 seconds) to open. STRACE seems to indicate grinding on
/dev/dri and /dev/dri/* directory, iterating through many dri "devices or
renders" (I'm not sure what the devices do). Once launched, dolphin performs
normally (and in fact, is very fast).
STEPS TO REPRODUCE
1. Open dolphin
OBSERVED RESULT
Dolphin takes ~5 seconds to start.
EXPECTED RESULT
Dolphin should take far less than 5 seconds to start as nearly every other kde
program, or GIMP for example. This is definitely a CPU constrained device, but
there is clearly some sort of issue at play when examining strace output.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Ubuntu Desktop 20.10 (kubuntu-desktop packages/task
installed)
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.14.2
ADDITIONAL INFORMATION
Raspberry pi 4B w/ 8G ram running on sd card.
Full strace with times attached, here is a summary of the system calls:
------
raz@nibble:~$ cat dolphin.log | sort | uniq -c | sort -nr | head -10
3756 newfstatat(AT_FDCWD, "/dev/dri", {st_mode=S_IFDIR|0755, st_size=120,
...}, 0) = 0
3750 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=20000}, NULL) = 0
------
And here is a snippet of an example "grind iteration" against DRI targets:
------
19:16:36.103698 newfstatat(AT_FDCWD, "/dev/dri", {st_mode=S_IFDIR|0755,
st_size=120, ...}, 0) = 0 <0.000038>
19:16:36.103877 newfstatat(AT_FDCWD, "/dev/dri/renderD141", 0xfffff95d3740, 0)
= -1 ENOENT (No such file or directory) <0.000036>
19:16:36.104015 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=20000},
NULL) = 0 <0.000104>
19:16:36.104214 newfstatat(AT_FDCWD, "/dev/dri", {st_mode=S_IFDIR|0755,
st_size=120, ...}, 0) = 0 <0.000030>
19:16:36.104356 newfstatat(AT_FDCWD, "/dev/dri/renderD141", 0xfffff95d3740, 0)
= -1 ENOENT (No such file or directory) <0.000033>
19:16:36.104488 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=20000},
NULL) = 0 <0.000103>
19:16:36.104688 newfstatat(AT_FDCWD, "/dev/dri", {st_mode=S_IFDIR|0755,
st_size=120, ...}, 0) = 0 <0.000030>
19:16:36.104823 newfstatat(AT_FDCWD, "/dev/dri/renderD141", 0xfffff95d3740, 0)
= -1 ENOENT (No such file or directory) <0.000034>
19:16:36.104955 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=20000},
NULL) = 0 <0.000103>
19:16:36.105153 newfstatat(AT_FDCWD, "/dev/dri", {st_mode=S_IFDIR|0755,
st_size=120, ...}, 0) = 0 <0.000030>
19:16:36.105287 newfstatat(AT_FDCWD, "/dev/dri/renderD141", 0xfffff95d3740, 0)
= -1 ENOENT (No such file or directory) <0.000032>
19:16:36.105417 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=20000},
NULL) = 0 <0.000102>
-----
It appears to "failure iterate" across a lot of /dev/dri/renderDXXX devices
following this pattern.
--
You are receiving this mail because:
You are watching all bug changes.
