ASRock X570 Taichi shows weird VR power and temp values

sarge21rvb

New Member
See screenshots below, but I don't think the VRs are pulling 62kW, ha. Nor do I think the ambient VR temp is hotter than the surface of the sun. This error happens mostly under load, otherwise the values seem fairly normal. I can consistently reproduce this by resetting max/avg and running Cinebench for 5 minutes. Otherwise it'll pop up like this randomly.

I've attached the logging for the runs that produced this error and a report.

Also, occasionally the DIMM temps will show strange values, like DIMM 2 reading 20F below ambient and I've seen values as low as -30C on different DIMMs.

This screenshot has two VR sections, but sometimes it's only one.
Screenshot 2021-02-01 122311.png


Here's a second screenshot where there's only one VR section with even crazier values.
1612201532428.png

Thanks!
 

Attachments

  • Vr sensor bug.HTM
    257.6 KB · Views: 1
  • VR sensor Bug.txt
    104.8 KB · Views: 1
Those are of course invalid readouts that could be caused by collision with other monitoring software. Are you running some other such tools along with HWiNFO?
 
Not that I know of. Asrock's A-Tuning runs at start to apply the custom fan curves, but I don't think it monitors those sensors, just chipset and CPU temps. Only other possibilities are iCUE and GSkill's RGB software, neither of which monitor MB temps to my knowledge. I'm monitoring CPU and GPU temps on my StreamDeck, but that plugin uses HWiNFO to pull the information.
 
AFAIK ASRock A-Tuning is accessing those VRM sensors, so try without it.
iCUE and GSkill's RGB software are other candidates. These might not be accessing the same sensor, but the same interfaces.
And AFAIK neither of those tools was made to be compatible with other monitoring tools, they don't care about playing fair with others.
 
It was the GSkill App. Not surprised. Stayed normal once I turned that off and left the others on. I'm sure there's not much you can do about it, but at least you're aware, I guess, ha. Thanks for your time.
 
Confirms that my "hate" on RGB controlling software is justified, and RGB capability it self is the new plague of modern systems...!
 
Confirms that my "hate" on RGB controlling software is justified, and RGB capability it self is the new plague of modern systems...!
Yeah, iCUE isn't terrible because at least it's a bunch of different products unified in one piece of software (even if they're all Corsair), but there definitely needs to be a unified, open-source standard for RGB control. It's not going anywhere any time soon, so it'd be nice to have alternatives.

I don't think RGB is a plague. That's catastrophizing something that's inconvenient at worst. I understand you're being hyperbolic, but RGB is by no means a requirement.
 
Yeah, iCUE isn't terrible because at least it's a bunch of different products unified in one piece of software (even if they're all Corsair), but there definitely needs to be a unified, open-source standard for RGB control. It's not going anywhere any time soon, so it'd be nice to have alternatives.

I don't think RGB is a plague. That's catastrophizing something that's inconvenient at worst. I understand you're being hyperbolic, but RGB is by no means a requirement.
No its not a requirement but users are forced to deal with it with one or another way. My current MSI and previous ASUS GPUs have/had RGB and wanting to turn them off. Both MSI DragonCenter and ASUS Aura had brought such problems that I was forced to have the RGBs on in the end along with fresh(cleaned) Win10 install.
The only software that has over a year to give me trouble is iCUE (CorsairLink protocol) that I "need" to control the Corsair AIO
 
I'm afraid there's nothing I can do here if some software vendors refuse to play fair with others. Corsair is notoriously known for this, but there are others as well.
Regarding RGB, this technology was very badly designed IMHO:
- RGB DIMMs used a protocol to send RGB commands by writing to the same address as the DIMM/SPD. This resulted in corrupted SPD EEPROM content on many modules when the controlling applications went into conflict with other tools.
- Some RGB controllers on several other devices (i.e. some GPUs and motherbaords) use a very inconvenient designed controllers that can cause several issues (including a system crash) when someone just queries them (i.e. attempts to read their data) via I2C.
So I share the hate with Zach :D
 
Back
Top