Created attachment 133986 [details] 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.
Just remembered some other details: composition is disabled, but it did the same with xrender and all versions of OpenGL. Also, this device does have 3d acceleration turned as evidenced by glxgears and firefox hardware acceleration working.
There are very little chances Dolphin is directly concerned. > many dri "devices or renders Those are direct rendering infrastructure, i.e gpu file descriptors. > composition is disabled, but it did the same with xrender and all versions of OpenGL That's probably relevant. Dolphin is not very likely to cause issues with loading Gpu drivers. This probably is an issue with one of its dependencies, I would guess solid. Is it always reproducible ? Is it reproducible with the command `solid-hardware list` ? Is it reproducible with other KDE Apps ? Plasmashell, Ark or gwenview for instance ? Or other apps ?
So, I have since moved on to Manjaro which is on a much more recent version of kde plasma and dolphin starts instantly, so whatever caused this has obviously been resolved or is specific to something ubuntu 20.10 was doing. If there is a desire, I can load ubuntu up on an sd card and see if it still does this and further troubleshoot, but my suspicion is that it has been resolved.
Phew! No need, thanks for the update. :)