https://bugs.kde.org/show_bug.cgi?id=401088
Tim Mohlmann <muhlem...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |muhlem...@gmail.com
--- Comment #16 from Tim Mohlmann <muhlem...@gmail.com> ---
I'm seeing the same issues on Arch Linux. This is a fresh install, 2 days old.
I've been working on trying to trace the problem for this.
System information:
Operating System: Arch Linux
KDE Plasma Version: 5.18.4
KDE Frameworks Version: 5.69.0
Qt Version: 5.14.2
Kernel Version: 5.6.7-arch1-1
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-6700T CPU @ 2.80GHz
Memory: 15,5 GiB of RAM
The warning of "Filesystem mounted at "x" is not responding" appears from time
to time after boot. I believe this is only a SYMPTOM and not the problem. My
setup uses multiple disks: NVMe for root, SDD for other stuff and an HDD for
archives. In the 3 years I'm running KDE (thru Gentoo, Kubuntu, Fedora, Debian
and now Arch) I've never had problems with a slow start of Plasma. Free space
calculation by df is instant:
tim@sky> time df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 8121464 0 8121464 0% /dev
tmpfs 8148440 78328 8070112 1% /dev/shm
tmpfs 8148440 12904 8135536 1% /run
tmpfs 8148440 0 8148440 0% /sys/fs/cgroup
/dev/dm-0 241725980 37445636 191971616 17% /
tmpfs 8148440 12 8148428 1% /tmp
/dev/mapper/ssd 244182200 128572228 113760108 54% /var/lib/libvirt/images
/dev/mapper/ssd 244182200 128572228 113760108 54% /home/tim/Pictures
/dev/mapper/ssd 244182200 128572228 113760108 54% /var/lib/docker
/dev/mapper/hdd 732558200 129478868 601648348 18% /home/tim/Videos
/dev/mapper/hdd 732558200 129478868 601648348 18% /home/tim/Archive
tmpfs 1629688 4 1629684 1% /run/user/1001
tmpfs 1629688 12 1629676 1% /run/user/1000
df 0.00s user 0.00s system 70% cpu 0.006 total
In order to further rule out the suggestion of free space calculation taking
long, I've disabled all other disks but root in /etc/fstab and /etc/crypttab.
Including swap. Leaving only the NVMe root partition:
tim@sky> lsblk
NAME MAJ:MIN RM SIZE RO TYPE
MOUNTPOINT
sda 8:0 0 232.9G 0 disk
sdb 8:16 0 698.7G 0 disk
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 234.5G 0 part
│ └─luks-2d922197-ec31-4ef6-864d-ebb772698177 254:0 0 234.5G 0 crypt /
└─nvme0n1p2 259:2 0 4G 0 part
This did not make any difference. So I installed systemd-bootchart to see
what's "hanging". I've disabled all system services not needed for this test.
Also, I created a new user account without customization. Logged it in once to
initialize the home directory. Configured "Auto Login" in sddm for this test
user.
If you observe attached bootchart you'll see the following data:
- At 4.2 seconds: "plasmashell" starts
- For 2.1 seconds there is actual cpu activity
- At 6.3 seconds: "plasmashell" seizes all cpu activity. Except for
systemd-bootchart there is no other resource utilization.
- At 19.5 seconds:, a single IO write. Probably a sync operation and unrelated
to plasma. No other IO operations are done during the freeze period.
- 30.9 seconds into boot plasma continues to have activity.
- 31.8 seconds into boot Dolphin starts. This was a manual action by me to mark
that the panel appeared in plasma.
I used KSystemLog to filter and extract the plasmashell logs. I will attach it
also, but did not find what causes the freeze. It does show that there is also
a freeze period in output.
My conclusion: this is not a system performance problem. Plasmashell freezes
during start for no apparent reason. It is a static freeze of ~25 seconds.
Which is also what
Musikolo noted in his comment.
--
You are receiving this mail because:
You are watching all bug changes.
