Hardware monitoring sensors under /sys/class/hwmon/ are not updated automatically

[leinardi]

I'm not sure if this is the expected behavior but the values under /sys/class/hwmon/ are not automatically updated. For example the CPU temperature value under /sys/class/hwmon/hwmon0/temp1_label gets updated only if I manually execute the command sensors. This is unfortunately breaking other monitoring software like system-monitor where the temperature value get stuck for very long times despite setting the update refresh time to 3000 ms.

System info:

System:    Host: c7h Kernel: 5.3.0-050300-generic x86_64 bits: 64 Desktop: Gnome 3.32.2 
           Distro: Ubuntu 19.04 (Disco Dingo) 
Machine:   Type: Desktop Mobo: ASUSTeK model: ROG CROSSHAIR VII HERO v: Rev 1.xx serial: <root required> 
           UEFI [Legacy]: American Megatrends v: 2801 date: 09/11/2019 
CPU:       Topology: 8-Core model: AMD Ryzen 7 3800X bits: 64 type: MT MCP L2 cache: 4096 KiB 
           Speed: 2195 MHz min/max: 2200/3900 MHz Core speeds (MHz): 1: 2195 2: 2195 3: 2195 4: 2196 5: 2198 
           6: 2196 7: 2195 8: 2196 9: 2195 10: 2195 11: 2195 12: 2195 13: 2195 14: 2191 15: 2197 16: 2194

[leinardi]

Just a small update: k10temp updates the value of /sys/class/hwmon/hwmon1/temp1_input automatically so, in theory, it should be possible to do it.

[electrified]

This driver implements the hwmon interface in the same way as other drivers (including k10temp). The values are updated when the sysfs interface is called.

So simply doing cat /sys/class/hwmon/hwmon0/temp1_input repeatedly should be enough to see changing values.

Under the hood, all programs get the sensors data the same way from sysfs these days - including sensors. sensors uses libsensors which itself simply gets the data from sysfs. Therefore it shouldn't make any difference whether you are using sensors or your gnome applet.

What I think you may be seeing is issues with ASUS WMI and Ryzen 3000 CPUs - sometimes the sensor values stop updating (see https://rog.asus.com/forum/showthread.php?112744-Crosshair-VI-Wifi-fan-control-sensors-are-broken for background)

I had hoped that those issues would be resolved in the latest BIOS however..

[leinardi]

Hi @electrified, thank you for the quick answer. But I still think there is some kind of link between the invocation of sensors and the refresh of the hwmon files. Please check this video I recorded: https://www.youtube.com/watch?v=Yz6Cw913PnM

You can clearly see that the file is updated every couple of seconds if I constantly call sensors using watch or manually running it and, when I don't do it, the file isn't updated at all.

Let me know if you want me to do more tests.

[electrified]

I can't watch the video as it is private.

On Wed, 25 Sep 2019, 1:52 pm Roberto Leinardi, notifications@github.com wrote:

Hi @electrified https://github.com/electrified, thank you for the quick answer. But I still think there is some kind of link between the invocation of sensors and the refresh of the hwmon files. Please check this video I recorded: https://www.youtube.com/watch?v=Yz6Cw913PnM

You can clearly see that the file is updated every couple of seconds if I constantly call sensors using watch or manually running it and, when I don't do it, the file isn't updated at all.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/electrified/asus-wmi-sensors/issues/39?email_source=notifications&email_token=AAAZFKTR66EDK7W6AEXGPHLQLNNHXA5CNFSM4I2FBNGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7RY66Y#issuecomment-535007099, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAZFKSAU2ZGN65UFA4BFVTQLNNHXANCNFSM4I2FBNGA .

[leinardi]

Sorry, now should be reachable.

[electrified]

That is strange!

The only thing I can think of at the moment is repeatedly reading 1 value won't trigger a bank switch operation, whereas reading all the sensor values will.

In your loop catting sysfs, can you try reading 1 value from an EC source, and 1 value that comes from an SIO source, (or even cat all the values) and see if that results in changing values, as that should trigger a bank switch. E.g. reading "CPU temperature" and then "CPU VRM output current" should do the trick.

This image from SIV shows which sensors are in which sources (banks).

https://user-images.githubusercontent.com/103082/51493449-4d9a0d00-1dad-11e9-88fb-6e43c591786d.PNG

I'm away from my desktop computer at the moment so can't investigate on my system.

[leinardi]

Yep, I think you are into something: if I run watch "cat /sys/class/hwmon/hwmon0/curr1_input" it's the same as running watch sensors.

As soon as I stop watching /sys/class/hwmon/hwmon0/curr1_input the value of temp1_input stops getting updated.

[electrified]

OK great :).

As a workaround I'd suggest adding VRM current to the gnome applet, and I'll investigate if this is a regression in recent BIOSes, or just something that hasn't been noticed previously due to most people monitoring a number of sensors across SIO and EC.

[leinardi]

just something that hasn't been noticed previously due to most people monitoring a number of sensors across SIO and EC.

Perhaps #37 is related to this issue. Same MoBo btw.

[electrified]

Hi @leinardi I have made a change that should fix this: https://github.com/electrified/asus-wmi-sensors/commit/8f5eaec0b29800f78999d8817d0c8fde14e978cd

Can you update and see if it is now working as expected?

Thanks.

[leinardi]

It works like a charm now! Thanks for the fix!