Created attachment 117938 [details] screenshot of widget, ksysguard, and /proc/stat output SUMMARY Even with everything closed, I recently found the CPU Load Monitor widget was showing 1 CPU core was at 100%. KSysguard "System Load" is showing that same CPU maxed. top, htop, and /proc/stat do not show the high usage. STEPS TO REPRODUCE 1. Cause unknown. 2. Let me know what I need to do to get you information you need. OBSERVED RESULT CPU core at 100% in ksysguard and widget, but 2% in top, htop and /proc/stat EXPECTED RESULT CPU usage data show be the same across the board. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.54.0 Qt Version: 5.12.0 ADDITIONAL INFORMATION My system has been up for 10 days and plasmashell crashed once without restarting so I started it back up with "kstart5 plasmashell". If another process is scheduled to take on that CPU core at 100%, then the 100% moves to a different core. EG, cpu1 is at 100% now. If another program grabs ahold of that core, then the 100% may move to cpu0. Even after killing ksysguardd, which also restarts it, 1 core is still pegged at 100%. Again, I don't believe that high usage is actually happening. cpu 54455067 917166 20201837 255970922 13509992 3617901 2264309 0 9059307 0 cpu0 14057889 245901 5012493 64477240 3113544 373252 483190 0 2354530 0 cpu1 13521184 216043 4973721 63463397 3212759 1772039 533901 0 2208023 0 cpu2 12932555 218534 5148656 63653809 3920836 1069710 779397 0 2174340 0 cpu3 13943438 236685 5066965 64376474 3262852 402899 467819 0 2322412 0
Here htop, ksysguard and cpuload widget also show different values of cpu/cores usage. Operating System: Arch Linux KDE Plasma Version: 5.15.1 KDE Frameworks Version: 5.55.0 Qt Version: 5.12.1 Kernel Version: 4.20.11-arch2-1-ARCH
What happens if you create a new diagram for the cpu load, does it show the same symptoms? To do so go File -> New Tab, OK Open Sensor Browser (click and drag from the right side of the ksysguard window), search for cpu load, drag & drop the sensors on a row. Also to rule out any hiccups in the system, it would be good if you could do a full system reboot.
That reply would've been more helpful sooner rather than over 1 month. I ended up updating my system which also required a reboot and I haven't had the issue. That was the ONLY time I've ever noticed the issue which is why time was important in getting it debugged to figure out the cause. I don't recall if I had done the "new tab" in ksysmon, but given that the sensor widget also reflected the same issue, I'm led to believe the issue lay with whatever data source they got their information from... and THAT is what I'd like to know.
(In reply to naroyce from comment #3) > That reply would've been more helpful sooner rather than over 1 month. > > I ended up updating my system which also required a reboot and I haven't had > the issue. > > That was the ONLY time I've ever noticed the issue which is why time was > important in getting it debugged to figure out the cause. > If you need urgent help, the bugtracker is *really* not the place to go. KDE provides a forum, MLs, IRC and matrix channels - and archlinux as well. Which are actually intended for live support, whereas the bugtracker is not. > I don't recall if I had done the "new tab" in ksysmon, but given that the > sensor widget also reflected the same issue, I'm led to believe the issue > lay with whatever data source they got their information from... and THAT is > what I'd like to know. > You can find a link to the source here: https://kde.org/applications/system/ksysguard/ (under Development Information) For further assistance please use one of the support channels mentioned above.
Yeah, IRC is really the first place I go, but when it comes to bugs that I chat about, no one says a word half of the time (guesstimation). I check IRC first to see if anyone has experienced the issue and it may very well be that the issue (not this one in particular) is not a bug, or it's known and already been posted. It wasn't "urgent" in the sense that I couldn't use my computer or anything, but I wasn't going to be able to keep my system up in perpetuity, with no knowledge of when/(if) someone would address it... in this case over 1 month. I see stat.c using "FILE *stat = fopen("/proc/stat", "r");", so that makes it even more confounding that the output would be different. Should it happen again, I'll just download the source and "try" to debug it myself. It sounds like that's the best advice I'd get from here. I'll just have to figure it out (if it happens again).