SUMMARY In Manjaro stable for the RPI4 (that being rolling is already at plasma 5.21.2 and framework 5.80), I am unable to use the plasmoid meant to show the cpu load (there are many, tried all those installed with the system). They remain blank, in their config interface it is impossible to find any sensor and when they are placed on the desktop or on the bottom panel cause a 100% cpu usage in ksystemstats. Invoking ksysguard starts an application providing the cpu load information correctly, though. It is unclear to me if this is Manjaro specific, ARM/RPI4 specific or a more general issue. I suspect it has to do with the system monitoring renew. Specifically, I don't know if this may be due to the plasmoid seeking some kind of interfaces and ksystemstats providing others. Do the plasmoids require updating? Is ksystemstats meant to provide a compatible interface? The fact that ksystemstats does not seem to support any standard command line option (-h --help, --version) to find out what it is and at what version it is, nor any diagnostic option and does not have help information is also a bit disorienting. Will this be added later? STEPS TO REPRODUCE 1. Add a cpu load plasmoid to the desktop (e.g. individual core load or total load) 2. Check the system load with top OBSERVED RESULT The plasmoid remain blank. Tryng to configure it show it "configured" with sensors having no name, trying to change that makes these preconfigured sensors disappear and no other one available. Top reveals ksystemstats using 100% of one cpu core. EXPECTED RESULT The plasmoid should work out of the box. Trying to configure it should show some available sensors. Ksystemstats should maintain a very low impact on the system resources. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro ARM Stable (RPI4) KDE Plasma Version: 5.21.2 KDE Frameworks Version: 5.80
When this happens, is the ksystemstats daemon running? It is supposed to be autostarted when anything that uses it appears, when then tear itself down automatically when the last user quits. Is this happening only login, or are the widgets blank the moment you add them?
As mentioned, ksystemstats appears to be active and jumps to 100% CPU usage by adding the plasmoids. So it seems to get started appropriately, but then something goes wrong. The issue is immediately present after adding the plasmoid, not just a login. I have noticed that other cpu-load related plasmoids that can be downloaded rather than being readily available appear to work, though partially. However, with them, ksystemstats does not seem to run (e.g., I see that the "system load viewer" plasmoid version 0.8 by Martin Yrjölä works, even if the "show CPUs separately" option does not). Is it based on a different approach? Also running ksysguard works (as mentioned) and does not start ksystemstats. Hence, my impression is that some plasmoid rely on a "new" framework using the ksystemstats daemon, that the daemon gets started properly when needed, but does not work. It fails to provide data to the plasmoids and it enters some state where it uses all the available resources of the core it runs on. I wonder if this is ARM specific or RPI4 specific or is due to a packaging or permission problem specific to arch/manjaro.
Could be one or the other, yeah. Are you using systemd startup, or not?
Yes manjaro uses systemd.
No I mean http://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
@Nate Graham sorry I missed your previous question. Catching up... From the document you linked, I believe that this is the needed info: ''' systemctl --user status plasma-plasmashell.service ○ plasma-plasmashell.service - KDE Plasma Workspace Loaded: loaded (/usr/lib/systemd/user/plasma-plasmashell.service; disabled; vendor preset: enabled) Active: inactive (dead) '''
Possibly not relevant. However, if you try to activate the service manually you get ''' systemctl --user start plasma-plasmashell.service systemctl --user status plasma-plasmashell.service ○ plasma-plasmashell.service - KDE Plasma Workspace Loaded: loaded (/usr/lib/systemd/user/plasma-plasmashell.service; disabled; vendor preset: enabled) Active: inactive (dead) Apr 28 09:14:16 systemd[694]: Starting KDE Plasma Workspace... Apr 28 09:14:17 systemd[694]: plasma-plasmashell.service: Deactivated successfully. Apr 28 09:14:17 systemd[694]: Started KDE Plasma Workspace. ``` ... after which the behavior of the widgets and the systemstat daemon does not change (widgets not working, daemon using 100% of one core).
KDE Frameworks update to 5.81 has not fixed the issue.
Thanks for the info.
Tried to launch ksystemstats manually, from the command line (incidentally, not so nice that there is no documentation at all, nor response to invoking with --help. Unclear to me if there is any way to make it print some debug info). Also in this case, ksystemstats gets in an "active wait" mode, using up 100% cpu. Trying to debug using strace, you can see that after some initial steps it enters in a situation where it keeps trying to read from file descriptor 8, but reads nothing. The latest openat returning file descriptor 8 seems to be /proc/cpuinfo. So my impression is that ksystemstats does not know how to parse the cpuinfo for ARM (or at least for the RPI4 Broadcom BCM2711 cpu) and remains confused.
A few additional notes: * just observed that ksystemstats belong to a ksysguard package on my distro. Wonder if the "product" field should be changed to ksysguard. * ksysguard package on my system comes with plasma 5.21.5 * just learned about the kstatsviewer command. It also hangs on my system when launched as ksytatsviewer --list
Issue is still present as of plasma 5.22.5, frameworks 5.87.0
I think that ksystemstats is uninstalled from your system, it happens to me. Try to install it. Here's the instructions to install ksystemstats. Enable the repository: # sudo add-apt-repository ppa:kubuntu-ppa/backports Update the package index: # sudo apt-get update Install ksystemstats deb package: # sudo apt-get install ksystemstats More info. https://ubuntu.pkgs.org/21.04/kubuntu-backports-amd64/ksystemstats_5.22.5-0ubuntu1~ubuntu21.04~ppa1_amd64.deb.html
As mentioned above, ksystemstats is installed. > As mentioned, ksystemstats appears to be active and jumps to 100% CPU usage by adding the > plasmoids. So it seems to get started appropriately, but then something goes wrong. ps shows /usr/bin/ksystemstats getting autostartd when the plasmoid is added, but then ksystemstats goes in active wait for something using 100% CPU. My feeling is that it may try to parse data from some interface remaining in active wait because it is not getting something that is expected (most likely because it waits for something that is X86 specific and not present on ARM systems).
stracing ksystemstats shows it opening /proc/cpuinfo, reading from it some text (the last string I see on the trace is about some bogomips value, but this may be due to strace string truncation). Then ksystemstats keeps repeating read attempts from that file always getting nothing. To me this is ksystemstats trying to read the file seeking for something, not finding it (because the virtual file misses some fields on ARM wrt X86 and has a slightly different format) arriving at the end of the file and stubbornly keeping to attempt reads.
I got this bug too on arm, a Mekotronics R58X (RK3588 EDGE LP4x V1.0 BlueBerry Board). Stracing it, it gets stuck in reading /proc/cpuinfo, like how Sergio reported. It goes like: ``` mprotect(0x7f9f2a1000, 4096, PROT_READ) = 0 write(3, "\1\0\0\0\0\0\0\0", 8) = 8 openat(AT_FDCWD, "/proc/cpuinfo", O_RDONLY|O_CLOEXEC) = 7 statx(7, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0444, stx_size=0, ...}) = 0 statx(7, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0444, stx_size=0, ...}) = 0 read(7, "processor\t: 0\nBogoMIPS\t: 48.00\nF"..., 16384) = 1923 read(7, "", 14461) = 0 read(7, "", 16384) = 0 read(7, "", 16384) = 0 ``` And spams `read(7, "", 16384) = 0` forever. ``` [bill88t@r58b | ~]> cat /proc/cpuinfo processor : 0 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x2 CPU part : 0xd05 CPU revision : 0 processor : 1 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x4 CPU part : 0xd0b CPU revision : 0 processor : 2 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x4 CPU part : 0xd0b CPU revision : 0 processor : 3 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x4 CPU part : 0xd0b CPU revision : 0 processor : 4 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x4 CPU part : 0xd0b CPU revision : 0 processor : 5 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x2 CPU part : 0xd05 CPU revision : 0 processor : 6 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x2 CPU part : 0xd05 CPU revision : 0 processor : 7 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x2 CPU part : 0xd05 CPU revision : 0 Serial : 8d3a9fcd2babbc55 ``` ``` extra/ksystemstats 5.27.8-2 (171.7 KiB 1023.5 KiB) [plasma] (Installed) A plugin based system monitoring daemon ```