"CPU Core VID (Effective)" vs "Core VIDs"

PiersJH

Active Member
I assume the 'Core VIDs' measures are less accurate? If not, are the data sources from different points? The popup explanation makes sense, but I would expect to see the highest 'VID (Effective)' value match the higher 'Core VIDs' value.

Example:
"CPU Core VID (Effective): 1.55000V"
"Core VIDs: 1.48125V" (highest value shown)
 

Martin

HWiNFO Author
Staff member
I don't think the effective VID has to be the highest one, but those values are also sampled via different methods so it's possible that the different source/sampling time plays some role too.
 

PiersJH

Active Member
I don't think the effective VID has to be the highest one, but those values are also sampled via different methods so it's possible that the different source/sampling time plays some role too.
Given the variation, which would you say is more accurate and how accurate? Is it a case of Vcore vs VDDCR CPU, with the latter being much more accurate? If so, why include the least accurate measure as default?
 

PiersJH

Active Member
Sorry, I cannot comment further about those values.
I may have possibly found a fix to the issue and thought I'd run it by you given your experience with I2C/SMBus and my understanding of how HWiNFO reads the data. If you don't want to read the wall of text below (it provides context), I've put the main question for you in bold text at the bottom of the post.

Summary
I'll use bullet points to make it shorter.
  • Received new PC
  • Installed Windows 11
  • Installed drivers for devices from motherboard vendor's website
  • Installed AMD Chipset Drivers (message at the end said 'Success' for all components, and the log file showed each driver as 'success')
Testing
With the above, it's a very standard process for any new build or OS reinstall. I then left it for a while until I noticed VID reaching 1.55000V and created this thread.

However, the other evening I was looking through Device Manager at the PSP device and noticed that although Windows said the device is working properly, under the item's Events tab, it showed that the device had never started 'Device not started'. I did a test and uninstalled the PSP device, deleted the driver, scanned for new hardware and an unknown security device showed (obviously the PSP device). I manually selected a driver from the unpacked AMD Chipset Driver package (3.10.22.706). The status then changed to 'Device started'.

Since that seemed to work, I thought I'd look at other drivers installed by the AMD Chipset Driver installer. Most of them had the same issue - no yellow warning triangle, a message saying the 'device is working properly', but under Events the most recent log showing 'Device not started'.

AMD I2C Controller driver / GPIO3 / SMBus
The AMD I2C Controller driver had the same issue - alternating 'Device configured' and 'Device not started' messages - these correspond to the dates I installed new chipset drivers.

As mentioned above, no 'yellow warning triangle' was displayed and under 'General', and the device status showed as "This device is working properly"

1641494750831.png1641494620440.png

After uninstalling the device -> deleting drivers (if given the option) -> scan for new hardware -> manually select the driver from the driver package, it finally seemed to work, although installed a driver from 2019. Updating the driver using Device Manager did not work, so I repeated the above steps (uninstalled, delete driver, scan, etc.) and Windows automatically selected the latest driver.

1641495175844.png

Here's the two events that should have happened after using the AMD installer.

Code:
--- EVENT [06/01/2022 17:51:23]

Device ACPI\AMDI0010\3 was configured.

Driver Name: oem36.inf
Class Guid: {4d36e97d-e325-11ce-bfc1-08002be10318}
Driver Date: 01/11/2021
Driver Version: 1.2.0.118
Driver Provider: Advanced Micro Devices, Inc.
Driver Section: amdi2c_Device.NT
Driver Rank: 0xFF0001
Matching Device Id: ACPI\AMDI0010
Outranked Drivers: amdi2c.inf:ACPI\AMDI0010:00FF0001
Device Updated: false
Parent Device: ACPI_HAL\PNP0C08\0

--- EVENT [06/01/2022 17:51:23]

Device ACPI\AMDI0010\3 was started.

Driver Name: oem36.inf
Class Guid: {4d36e97d-e325-11ce-bfc1-08002be10318}
Service: amdi2c
Lower Filters:
Upper Filters:

Rather than repeating the above with screenshots, I'll simply state I did the same with each device that the AMD Chipset Driver installer told me it had installed. Even the SMBus, where there is no need for a driver so a 'dummy' is used, had the wrong one - it was a null driver. The correct 'dummy' worked. Here's a screenshot that probably explains it better as I'm tired.

1641495578737.png

The entire purpose of creating this thread is that when correcting the I2C driver issue, I noticed that VID no longer went above 1.50000V. I tried everything I could over a period of three days testing to get it to go to 1.55000V as it did before, but no (at least not so far). On top of that, reported clocks ~5% higher, not that it really matters.

The CPU is still in stock settings, apart from XMP being enabled (currently running an AVX2 workload, hence the lower clocks).

And finally getting to the point, do you believe that a 'faulty' I2C driver could have impacted readings from the Nuvoton super I/O in some way specifically in HWiNFO? All I did was to make sure the devices had the correct drivers and that the Event tab showed the most recent log as 'Device started'.

I've not changed anything else. As mentioned above, I've now tried everything that used to make the VID go to 1.55000V (and VDDCR SVI2 TFN up to 1.55000V as well) over a period of three days and it seems to now be working correctly (VID Effective never goes above 1.50000V). What sort of behaviour would you expect to see with essentially no I2C driver installed?


1641495790598.png
 
Last edited:

PiersJH

Active Member
@Martin have you had a chance to look at the above post? I'm not asking for any sensitive data, merely your opinion (which I understand is entirely optional) on my theory, given that you have years of highly skilled experience with I2C data.
 

Martin

HWiNFO Author
Staff member
Sorry, I have no idea. This sounds like alchemy and not easy to make any judgements.
 

PiersJH

Active Member
Sorry, I have no idea. This sounds like alchemy and not easy to make any judgements.
Indeed, which is why I was surprised that it appears to have fixed the issue entirely. Incorrectly installed drivers for the GPIO, SMBus (not that it technically needs a driver), I2C, and PCI (thanks, AMD!) = incorrect/out of specification readings. Correct drivers = correct readings. It entirely depends upon how much HWiNFO uses the Windows driver to take sensor readings, and I suspect the answer to that is 'it takes readings straight from the I2C'

I realise no software is perfect, and HWiNFO can only rely upon what the sensors report. My 10W J5005 is a great example - HWiNFO reports boost speeds of 3600 MHz on all four cores (I've even seen over 4 GHz reported once), yet its maximum all-core clock is 2.7 GHz :p
 

Martin

HWiNFO Author
Staff member
HWiNFO doesn't utilize those drivers, so it's rather just some coincidence.
 

PiersJH

Active Member
For anyone else in a similar situation. It's now been ~10 days since I appeared to have fixed the issue, and since then I've tried everything I can think of to force it to exceed the limit. The only change I made was to manually install the AMD chipset drivers (the latest available) one by one using Device Manager, and to not install the Power Management driver (which appears to be for Zen 2, but defaults to checked on Zen 3). I'm now seeing the "1.488" that many appear to have listed as the max VID over X time, and a maximum Effective VID of 1.50000V. The configuration below is 'auto' Vcore, XMP enabled, and that's it.

Here's a snapshot of 45 hours of use. In that time, I've run Prime 95 SSE 1C, BoostTester.exe for 1 hour, x265 with only 1T allocated, gamed, and other tasks. Those with the knowledge to understand the relationship between Zen 3 drivers and the hardware see it as either not related or unexplained, but that's the only change that was made. This thread can be closed if needed and I'd like to thank you for helping, Martin.

1641885855845.png

Edit: Current clocks and temps in above screenshot as that way because they've been encoding a queue of files for 28 hours.
 
Top