Bug 413615 - Hardware sensors are randomly freezing
Summary: Hardware sensors are randomly freezing
Status: RESOLVED UNMAINTAINED
Alias: None
Product: ksysguard
Classification: Unmaintained
Component: general (other bugs)
Version First Reported In: 5.17.1
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KSysGuard Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-30 01:12 UTC by Mircea Kitsune
Modified: 2024-09-23 21:00 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Screenshot of the empty fields (44.49 KB, image/png)
2019-10-30 15:58 UTC, Mircea Kitsune
Details
Screenshot of system monitor widgets freezing (85.84 KB, image/png)
2019-10-30 16:14 UTC, Mircea Kitsune
Details
Screenshot of disk sleep processes (317.27 KB, image/png)
2019-11-09 19:12 UTC, Mircea Kitsune
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mircea Kitsune 2019-10-30 01:12:30 UTC
I'm experiencing a bizarre problem since upgrading my motherboard. At random times, the hardware sensors appear to freeze and no longer deliver updates for several seconds at a time. I can see this in KSysGuard where I have a tab with a few charts showing CPU and GPU temperatures updated every second: Every now and then, the updates simply stop and the charts freeze in place. If I go to the default Process Table tab I still see activity there, but everything else (including the System Load tab, with CPU and RAM / SWAP history) stops. Switching between tabs or restarting the system monitor doesn't solve it. But if I wait somewhere over 10 seconds, they start working again. This never happened before and began with my upgrade.

The problem seems to be specific to KDE and not a high level sensor issue: I ran "watch -n1 sensors" in a console next to KSysGuard. When the system monitor froze, this command still continued to output updated temperatures without any lag.
Comment 1 Sam Dyer 2019-10-30 10:08:02 UTC
What operating system and software versions are you using?
Comment 2 Mircea Kitsune 2019-10-30 12:38:55 UTC
(In reply to Sam Dyer from comment #1)
> What operating system and software versions are you using?

openSUSE Tumbleweed x64, always the latest snapshot (I "zypper dup" daily). Latest official Kernel 5.3.7-1-default. Plasma & KSysGuard 5.17.1. If it's relevant, my new motherboard (which introduced the bug) is an ASUS PRIME X370-PRO running an AMD Ryzen 7 3700X CPU.

https://www.asus.com/us/Motherboards/PRIME-X370-PRO
https://www.amd.com/en/products/cpu/amd-ryzen-7-3700x
Comment 3 Mircea Kitsune 2019-10-30 15:58:52 UTC
Created attachment 123596 [details]
Screenshot of the empty fields

Here's a screenshot showing the oddity of the issue: I quickly restarted KSysGuard upon noticing the issue, then went to the System Load tab. Upon doing that I found not only the charts frozen, but the values didn't load at all and showed nothing (not even 0). I had to wait for roughly 5 seconds before it unfroze and the numbers appeared.

What's even worse is that if I shut down KSysGuard while this is happening, the CPU History tab is permanently cleared and no cores ever appear in it any more. I have to go to ~/.local/share/ksysguard/ and delete the file SystemLoad2.sgrd to make the system monitor generate a new one in which case the entries return.
Comment 4 Mircea Kitsune 2019-10-30 16:09:34 UTC
I just noticed one more thing: This also affects the system monitor widgets placed on the desktop. Ever since this issue started, I've been noticing that plasmoids such as CPU Load Monitor, Memory Status, Hard Disk Space Usage, Hard Disk IO Monitor, Network Monitor show fixed and incorrect values for several seconds at a time. For instance: The network monitor may say that I'm downloading at precisely 50 KB/s for 5 seconds in a row, although I'm clearly transferring nothing during this time... exact same thing with HDD I/O usage. For the first few days I thought some program started networking or using the HDD in an unusual way; It just now clicked that this is the same problem, after I noticed two different system monitors freezing and unfreezing this way at the exact same time.
Comment 5 Mircea Kitsune 2019-10-30 16:14:44 UTC
Created attachment 123597 [details]
Screenshot of system monitor widgets freezing
Comment 6 Mircea Kitsune 2019-11-07 19:37:35 UTC
I just discovered another important clue related to this issue. It's not just the sensors that are freezing: Other processes are too. I've been noticing this since I switched motherboards, but was convinced it was an entirely unrelated problem. I just now spotted that new applications will not start up while the sensors are frozen, but will start the moment they unfreeze.

Some practical examples: If I open a new tab in Firefox which requires opening a new Web process, Firefox will freeze during the 5 second period that sensors don't update. Or if I write "sudo zypper dup" in the console to do an update, my cursor moves to the next line when pressing enter, but nothing happens if the sensors are frozen at that time... the line asking me to input my password appears the moment they unfreeze. It also appears I can't close certain applications during a freeze: If I try closing Dolphin in such a moment, the window becomes gray and I'm asked if I want to terminate the unresponsive process... however it disappears and Dolphin closes normally at unfreeze.

So it seems something is blocking both the hardware sensors and some processes starting up or shutting down, though it seems not to affect processes that are already running. What could cause such strange behavior? Traditionally those things used to happen due to the disk I/O scheduler causing processes to go into disk sleep mode, but nothing seems to be using the hard drive while the problem occurs nor does KSysGuard show affected processes as being in "disk sleep". I already disabled SWAP with "swapoff -a" and it's not related to it.
Comment 7 Mircea Kitsune 2019-11-09 18:51:51 UTC
Turns out this might be related to disk sleeping after all: If I run "sudo zypper dup" in the console then look at zypper in KSysGuard, the sudo process does say "disk sleep" during the duration of the freeze.

My bet now is that the new motherboard is causing a new process to be spawned which is freezing the drive for other processes. Or could it be a disk scheduler bug? I seem to be running the proper BFQ scheduler just in case this matters.

mircea@linux-qz0r:~> cat /sys/block/sdb/queue/scheduler
mq-deadline kyber [bfq] none
Comment 8 Mircea Kitsune 2019-11-09 19:12:41 UTC
Created attachment 123815 [details]
Screenshot of disk sleep processes

I seem to be onto something! When sorting by process status in htop, I see a load of processes going into "disk sleep" mode during those freezes. Those shown with the red D here are included.

Question now is what's triggering it. Nothing appears to be causing unusual drive I/O... that is why I didn't suspect this in the first place, even though I knew the behavior is generally associated with the drive scheduler.
Comment 9 Mircea Kitsune 2019-11-09 20:00:32 UTC
After some more testing I have finally found the culprit: The freezes are being caused by the Network Manager and / or the WPA supplicant process. They are the first to go into disk sleep each freeze as shown by htop, dragging other processed down with them in the next second. Further more, clicking the NetworkManager icon in the system tray to list my connections often triggers such a freeze on the spot before the panel shows, identical to the one occurring automatically every minute!

Looking at /var/log/wpa_supplicant.log I'm seeing one message being constantly logged there (every few minutes). Not sure if it's related to the freeze but just in case:

1573327565.215899: wlan0: Reject scan trigger since one is already pending

I can confirm that disabling Wifi causes the problem to finally go away, a workaround I'll stick to for now as I don't currently need wireless internet on my desktop. This likely has something having to do with the Network Manager service.
Comment 10 Mircea Kitsune 2021-05-12 14:05:11 UTC
This still happens in the latest Plasma / Framework (5.21.4 / 5.81.0) even after I changed Linux distributions since reporting this (openSUSE Tumbleweed to Manjaro). As long as you have WIFI enabled without being connected to a network, various system processes randomly freeze for a few seconds in a periodic cycle, during this time not even system sensors will be updated and freeze in place. I have to keep WIFI disabled when not using it just to work around this problem.
Comment 11 Christoph Cullmann 2024-09-23 21:00:12 UTC
ksysguard is no longer maintained, in Plasma 6 there is the Plasma system monitor for this task.

If your issue still happens with the Plasma 6 replacement, please re-open and we can move this bug to the new product, thanks!