Anomalous sensor readings in HWiNFO64
- Thread starter whatever
- Start date
ajgringo619
New Member
Good to hear! Does it also fix the fans shutting off bug? I've installed v5603, but have been afraid to reinstall any sensor detection software, either in Windows or Linux.
ASUS WMI should be safe if properly implemented in BIOS and EC.
But one cannot exclude a case where a certain BIOS version would be buggy and fail to properly synchronize access to the SIO resulting in corruption of its state (which manifests as a fan failure or other power management issue).
But one cannot exclude a case where a certain BIOS version would be buggy and fail to properly synchronize access to the SIO resulting in corruption of its state (which manifests as a fan failure or other power management issue).
ajgringo619
New Member
The original BIOS I had on my board was v5601. Using this software on Linux - https://github.com/electrified/asus-wmi-sensors - I had the fans, CPU and chassis, randomly shut off. From reading their disclaimers and various on-going issues, this bug has been around for several BIOS revisions previous to v5601. Since upgrading to v5603, I haven't tried this software again. Since I'm now dual-booting with Windows 10, I should try to use this forum's software to see if this bug has been squashed. I was just hoping that someone else had tried it first.
I don't know what/how exactly Linux does, but sole support of ASUS WMI in an application/system is not the guarantee of mitigating the issue. One needs to avoid touching the SIO.
So if Linux has ASUS WMI support it won't help if some other component there is still accessing the SIO (i.e. lmsensors).
So if Linux has ASUS WMI support it won't help if some other component there is still accessing the SIO (i.e. lmsensors).
ajgringo619
New Member
In my case, I don't think lm-sensors has ever been the issue. According to the aforementioned software's notes, it does not poll SIO directly. Also, I have glances running 24/7, which polls what few sensors are detected without the WMI add-on (chassis/CPU fans are not among them).
Martin
Please tell me if I understand it right:
1. ASUS BIOS on a regular basis (say once a second) fills ASUS WMI buffer in memory with some values.
2. It fills the buffer regardless of whether any program actually uses these values.
3. This implementation could have bugs and could cause problems on its own, without any program accessing the buffer.
4. A program, which reads the buffer only, does not cause problems, because it does not touch m/b sensors in any way.
Please tell me if I understand it right:
1. ASUS BIOS on a regular basis (say once a second) fills ASUS WMI buffer in memory with some values.
2. It fills the buffer regardless of whether any program actually uses these values.
3. This implementation could have bugs and could cause problems on its own, without any program accessing the buffer.
4. A program, which reads the buffer only, does not cause problems, because it does not touch m/b sensors in any way.
1. Yes
2. Yes
3. Yes
4. Yes if the program does not touch the SIO registers directly and if the ASUS WMI is properly implemented
The problem here is that if any other program accesses the SIO registers directly it can cause issues. The BIOS and EC are constantly polling the SIO and if anything else does it too, it can cause a collision resulting in those issues due to a bug in the SIO chip. So ASUS WMI itself is not to resolve the problem, it's just to provide sensor values to other applications without the need to access the SIO and risk the collision. It also has to be properly implemented in BIOS so that it properly synchronizes with the EC. In the past when we worked with ASUS on solving the problem we tried several synchronization mechanisms with BIOS/EC, but none of them worked reliably, so ASUS offered this WMI interface.
2. Yes
3. Yes
4. Yes if the program does not touch the SIO registers directly and if the ASUS WMI is properly implemented
The problem here is that if any other program accesses the SIO registers directly it can cause issues. The BIOS and EC are constantly polling the SIO and if anything else does it too, it can cause a collision resulting in those issues due to a bug in the SIO chip. So ASUS WMI itself is not to resolve the problem, it's just to provide sensor values to other applications without the need to access the SIO and risk the collision. It also has to be properly implemented in BIOS so that it properly synchronizes with the EC. In the past when we worked with ASUS on solving the problem we tried several synchronization mechanisms with BIOS/EC, but none of them worked reliably, so ASUS offered this WMI interface.
Sorry, I just realized I wasn't correct above. The sensor buffer updates only if the "sensor_update_buffer" method is called.
So this provides some sort of synchronization for reading the buffer content, but if multiple applications call the update method they need to synchronize and interlock the update + read buffer.
So this provides some sort of synchronization for reading the buffer content, but if multiple applications call the update method they need to synchronize and interlock the update + read buffer.
So in fact software which uses ASUS WMI only could trigger some problems because it calls (potentially buggy) BIOS method. Without running the software it's not triggered because (potentially buggy) BIOS method is not called at all.
BTW I never had stability problems with ASUS WMI for 10 months using Prime X470-Pro but I faced the problems several times with direct access software during short period of time. To be fair I don't run HWiNFO for 24/7, just start it a few times a day to check some values.
BTW I never had stability problems with ASUS WMI for 10 months using Prime X470-Pro but I faced the problems several times with direct access software during short period of time. To be fair I don't run HWiNFO for 24/7, just start it a few times a day to check some values.
UPDATE:
Also tested HWINFO. The same thing happens, for some reason, cpu temp and cpu rpm remain stuck in a low value, after the screen turns off (power scheme) and comes up again. The latest hwinfo beta simply does not show temperature and rpm for my ASUS prime 730x pro.
Last edited:
There seems to be no problem when using hwinfo with some settings disabled and latest bios. I hope that whatever problems I was facing where do to the fact that after using aida64 which completely breaks sensors, I run hwinfo without restarting windows...
Is hwinfo working fine for you with full settings enabled?
Is hwinfo working fine for you with full settings enabled?
I'm not too sure that the CPU PLL OC has anything to do with temperature sensor settings or voltage to them...it's the voltage used to create the clock that the CPU runs at, not the voltage required to perform any tasks. It's also suggested to bump it up a bit when doing higher overclocks, and it definitely has a minimum when it comes to stability at certain clocks on that chip. In my MSI Z270 Gaming M7's BIOS, the setting has a range of 0.6000 to 2.0000, and defaults to 1.2000. I've also read that not all boards default to the same voltage either. When testing with my i7-7700K @ 4.8GHz, I was hitting ~86C with a 240 AIO. But after some testing, I found that the lowest my chip was stable was with the PLL OC set to 1.0500. 0.9000 wouldn't even boot, while 1.0000 booted, but was unresponsive once at the desktop. But with the 1.0500, my temps dropped from ~86C to ~67C after an hour of Cinebench R20 without an AVX offset. That's at 4.8GHz...5GHz needed at least 1.1000 to boot, and I'm still playing with it for stability. I just delided Thursday and have been having some fun. 
Personally, I don't see them adding a feature that would potentially give the user a false sense of security due to incorrect temperature readings. And if it was so dangerous, you'd think they'd have a big warning about it in the 'help' text of the BIOS. The core temps drop considerably, but the wattage used by the chip is the same, which is why most seem to think the readings are skewed. But...although the cores dropped by ~19C, the CPU's GT Cores only dropped by ~4C. The GT Cores are on the same chip, so if the CPU's cores are ~19C cooler, then shouldn't the GT Cores also see the same ~19C drop if the temps were skewed?
Personally, I don't see them adding a feature that would potentially give the user a false sense of security due to incorrect temperature readings. And if it was so dangerous, you'd think they'd have a big warning about it in the 'help' text of the BIOS. The core temps drop considerably, but the wattage used by the chip is the same, which is why most seem to think the readings are skewed. But...although the cores dropped by ~19C, the CPU's GT Cores only dropped by ~4C. The GT Cores are on the same chip, so if the CPU's cores are ~19C cooler, then shouldn't the GT Cores also see the same ~19C drop if the temps were skewed?
hideokuze
New Member
Still having these issues with an ASUS PRIME X470-PRO on firmware version 5603.
Fans are shutting off completely, readings are showing 5 million+ RPM, etc.
This may be an issue with ASUS and it's UEFI/BIOS, but ultimately this software is the only thing preventing overall system stability so I have had to uninstall it.
Fans are shutting off completely, readings are showing 5 million+ RPM, etc.
This may be an issue with ASUS and it's UEFI/BIOS, but ultimately this software is the only thing preventing overall system stability so I have had to uninstall it.
