SUMMARY Since Plasma 5.22.0 onwards, as packaged via Kubuntu Backports PPA, the System Monitor widgets for monitoring per-core CPU usage and memory usage display nothing on AMD Kabini APU. My guess is that this is possibly related to the migration away from KSysGuard since just rolling back the widgets to Plasma 5.21 did not resolve the problem. I had to roll back the whole platform to Plasma 5.21 before the monitor widgets work again. Interestingly, this only appears to be an issue on my AMD Kabini system. The System Monitor widgets work just fine on Plasma 5.22 with AMD Phenom II CPU and AMD Ontario APU. My other systems are using Ubuntu LTS and thus still using the old System Load Viewer - which I very much prefer (see Bugs #437114/#437124) - and so are not yet using the recent Plasma releases. I confirmed narrowed down the regression moving from Plasma 5.21.5 to Plasma 5.22.x after doing a clean OS installation. STEPS TO REPRODUCE 1. Have an AMD Kabini system (I recognise hardware-specific issues will be hard to diagnose so please advise what I can do to provide debugging information). 2. Install Kubuntu 21.04 and add System Monitoring widgets for Plasma 5.21. Observe that the widgets function as expected. 3. Install Kubuntu Backports PPA to update to Plasma 5.22. (At time of writing, currently has 5.22.3 but I was observing this problem since 5.22.0.) (I doubt the issue is specific to Kubuntu packaging since 5.21.5 works fine but if it is, let me know so I can advise them.) OBSERVED RESULT CPU and Memory monitor widgets are blank. EXPECTED RESULT CPU and Memory monitor widgets report current CPU and memory usage. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 21.04 KDE Plasma Version: Plasma 5.22.3 (at time of writing, problem observed since 5.22.0) KDE Frameworks Version: 5.84.0 Qt Version: 5.12.2 ADDITIONAL INFORMATION As already stated, please advise what I should do to provide additional information. It's not clear to me how system information is gathered by the widgets, so I'm not sure where to look for logs, etc.
I confirm the same behavior on Operating System: openSUSE Tumbleweed 20210723 KDE Plasma Version: 5.22.3 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.2 Kernel Version: 5.13.2-1-default (64-bit) Graphics Platform: X11 Processors: 4 × AMD A8-7650K Radeon R7, 10 Compute Cores 4C+6G Memory: 14.6 GiB of RAM Graphics Processor: AMD KAVERI I do not remember exactly what update caused that issue. However, it was working at the introduction of the new "System Monitor". Two notes: - "Total Sensors", "Sensors" and "Text-only Sensors" are empty. Looking for new sensors is failing (search field remains empty) - The old "KSysGuard" is working fine - all sensors seem to be available. Happy to help.
> - "Total Sensors", "Sensors" and "Text-only Sensors" are empty. Looking for new sensors is failing (search field remains empty) Based on that I assume running 'kstatsviewer --list' produces empty output, can you confirm? If yes, can you check if 'ksystemstats is running', if it isn't, what happens if you run it manually?
Interesting. Of course where the widgets work, kstatsviewer --list provides plenty of info. Going back to Plasma 5.22.3 on Kabini I do indeed find ksystemstats is not running. Running it manually simply returns 'Segmentation fault'. Not sure if I'm looking in the right place but KSystemlog shows kernel messages like ksystemstats[PID]: segfault at 8 ip <address> sp <address> error 4 in ksystemstats_plugin_lmsensors.so[address] Likewise systemd records messages like plasma-ksystemstats.service: Main process exited, code=killed, status=11/SEGV Anywhere else I should look/try/run for more information?
Here comes what I found: - 'kstatsviewer --list' provides info, so is NOT empty - ksystemstats is not running (checked with 'ps -ax | grep ksystemstats') - start of ksystemstats as user: Stops with message "Segmentation fault (Speicherabzug geschrieben)" - start of ksystemstats as root: Stops with message "kf.dbusaddons: DBus session bus not found. To circumvent this problem try the following command (with bash): export $(dbus-launch)" - Start of 'export $(dbus-launch)' as recommended: No output, no change in the behaviour of ksystemstats
Do you still have KSysguard installed? Because I didn't and so kstatsviewer -list reported nothing. (Seemed to 'hang' for several seconds before eventually returning to the command prompt.) At least we seem to have the same issue on the segmentation fault on ksystemstats. Interestingly, I get a different message if attemptign to run as root: Could not determine Plasma version, got: "The name org.kde.plasmashell was not provided by any .service files" Hope all of this is helpful in some way. Happy to continue testing.
Yes indeed, I have KSysGuard still installed, and it is working (that leads to my conclusion that actually all sensors are detectable). Well, as you said, I also hope this is all helpful information.
Plasma 5.22.4 packages just became available for my systems. I honestly wasn't expecting any difference from Plasma 5.22.3, but it seems to be working now...? * kstatsviewer --list reporting info again * ksystemstats is running * ksysguard is *not* installed I'm curious to know what changed with 5.22.4 for Kabini, but I'm just glad it's working again. @Sebastian - if/when you have the opportunity to try 5.22.4 see if that improves anything for you as well.
I found this commit: https://github.com/KDE/ksystemstats/commit/70550a94e1752a8adad577574ab3b051088f5a61 https://invent.kde.org/plasma/ksystemstats/-/merge_requests/8 For bug: https://bugs.kde.org/show_bug.cgi?id=439615 That report doesn't mention anything about hardware, but it seems related to this issue.
Thanks so ksystemstats is crashing, are you able to provide a backtrace of it? See also https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports This will also help confirm if it's indeed the crash that's fixed with above commit
I did a comparison between tags for 5.22.3 and 5.22.4 and there were only a handful of commits, with the one I quoted being the only meaningful change. I rolled back *only* the ksystemstats package back to 5.22.3 and the widget is broken again. So it seems to be the culprit and 5.22.4 resolves the issue (at least for me, can't speak for Sebastian). Lastly, I picked up this stack trace at the point of crash: #0 0x00007ffff1d6ad60 in SensorsFeatureSensor::update (this=0x5555555d4a30) at ./plugins/lmsensors/SensorsFeatureSensor.cpp:142 #1 0x00007ffff1d6993d in LmSensorsPlugin::update (this=<optimised out>) at ./plugins/lmsensors/lmsensors.cpp:61 #2 0x00005555555627cd in Daemon::sendFrame (this=0x7fffffffde40) at ./src/daemon.cpp:246 #3 0x00007ffff7be25c7 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x00007ffff7be672e in QTimer::timeout(QTimer::QPrivateSignal) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x00007ffff7bd802f in QObject::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x00007ffff7baa78f in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x00007ffff7c03533 in QTimerInfoList::activateTimers() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x00007ffff7c03e2c in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x00007ffff6b858eb in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #10 0x00007ffff6bd8d28 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x00007ffff6b83023 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #12 0x00007ffff7c04204 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #13 0x00007ffff7ba911b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #14 0x00007ffff7bb1604 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #15 0x000055555555a8fe in main (argc=<optimised out>, argv=<optimised out>) at ./src/main.cpp:29 It doesn't look obviously linked to the change in the commit, but I imagine you'd be more familiar with the code than I am.
that indeed looks like the same crash, marking it as such *** This bug has been marked as a duplicate of bug 439615 ***
Many thanks for your efforts. If I understand correctly, there is a commit already, and it should be fixed in 5.22.4. Just to mention, 5.22.4. has not released yet for openSUSE Tumbleweed. Usually the rollout takes some days.
For confirmation - update 5.22.4. has solved the issue.
Great!