SUMMARY Plasma System Monitor, and its widgets show 100% CPU usage on one core STEPS TO REPRODUCE Steps to reproduce are unknown; however, if you kill the kwin process (and wait for the shell to restart itself) the issue goes away until the next reboot. OBSERVED RESULT n/a EXPECTED RESULT n/a SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux, Kernel v6.4.4-arch1-1 KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION Here are some images of what I am seeing: [Widget](https://imgur.com/a/jXjHk2M) [System Monitor](https://imgur.com/a/YnjslJ1) [htop](https://imgur.com/a/qJuxV7X)
Same issue here, one of the cores incorrectly shows 100% usage. This is common for all kde apps and widgets but not btop, glances or any other 3rd party apps. I am also on Arch Linux, I tried both LTS and stable kernels just in case. I suspect this is not a System monitor issue but rather it's source.
Same here after latest update. Got 100% CPU usage on two cores after sign in as user, but can't find neither in the processtable nor top (or htop) such the process that triggers the load. Interesting observation: If I stop akonadi it goes down to one CPU, if I start the akonadi server again, it raises again up to two CPUs. System Information: | Operating System: Arch Linux | KDE Plasma Version: 5.27.6 | KDE Frameworks Version: 5.108.0 | Qt Version: 5.15.10 | Kernel Version: 6.4.4-arch1-1 (64-bit)
It seems that it belongs to MariaDB: if I stop also the mariadb.service, CPU load for all cores are gone. That explains why after stopping the akonadi server, only one core has the 100% load, since akonadi also uses MariaDB; if I run mariadb and akonadi, I get the load on two cores, if I stop both, the CPU usage is back to normal. That happens with kernel v6.4.4 as well as with LTS v6.1.39.
(In reply to Martin Schnitkemper from comment #3) > It seems that it belongs to MariaDB: if I stop also the mariadb.service, CPU > load for all cores are gone. That explains why after stopping the akonadi > server, only one core has the 100% load, since akonadi also uses MariaDB; if > I run mariadb and akonadi, I get the load on two cores, if I stop both, the > CPU usage is back to normal. > That happens with kernel v6.4.4 as well as with LTS v6.1.39. Yes, mariadb is indeed the cause of this, so this might not be a kde issue afterall? How can we determine what uses mariadb?
(In reply to Matej Mrenica from comment #4) > Yes, mariadb is indeed the cause of this, so this might not be a kde issue > afterall? How can we determine what uses mariadb? It looks like a kernel regression. I just downgraded to version 6.1.38-1-lts and the problem is gone. Since I am afraid of any negative site effects of downgraded components, I prefer to stay at the current kernel and decided to live with the problem. It seems that it is more a kind of cosmetic problem, because the system is not rather slow or does heat up. And it's also not shown in other applications like "top", or at the process table.
The same on arch linux, one core at 100% but htop shows all cores at 0%
(In reply to Jesus from comment #6) > The same on arch linux, one core at 100% but htop shows all cores at 0% In 'htop' press 'F2', then check in the "Display Options" the option "Detailed CPU time", and after that you see the IO-Wait for the core in the meters panel. The problem is, that in opposite to other tools like 'htop' the KDE system monitor reports IO-Waits as CPU usage; and that should be fixed.
(In reply to Martin Schnitkemper from comment #7) > (In reply to Jesus from comment #6) > > The same on arch linux, one core at 100% but htop shows all cores at 0% > In 'htop' press 'F2', then check in the "Display Options" the option > "Detailed CPU time", and after that you see the IO-Wait for the core in the > meters panel. > The problem is, that in opposite to other tools like 'htop' the KDE system > monitor reports IO-Waits as CPU usage; and that should be fixed. Ok, that shows one core at 100% but in gray color like disabled. Well it's not a critical bug, it will be fixed when someone who knows how to fix it has time to do it. Thank you
Issue seems to be fixed in kernel 6.4.8. It was still there in 6.4.7
I can confirm it's fixed in (kernel) 6.4.8.
Confirmed too, it's fixed in kernel 6.4.8
Yay, thanks!