The-Stilt

joined 11 months ago
[–] [email protected] 1 points 10 months ago

As for the cause, most likely interference from an another app, which does not implement the mutex to synchronize the hardware accesses. Many of the hardware accesses are indexed and an another app changing the index between HWiNFO specifying the correct index to access and actually reading the data out of it, can and will cause issues such as this.

DDR5 telemetry is read through the SMBUS from the SPDHUB. With an another app changing e.g., the SMBUS address or the index while HWiNFO is reading the data is likely to cause insane readouts such as this one. However, this can affect basically ANY of the monitoring values.

In most cases, the best place to start looking would be any other monitoring, CAM, RGB, etc. tools from third parties or the motherboard manufacturer.

[–] [email protected] 1 points 10 months ago

As for the cause, most likely interference from an another app, which does not implement the mutex to synchronize the hardware accesses. Many of the hardware accesses are indexed and an another app changing the index between HWiNFO specifying the correct index to access and actually reading the data out of it, can and will cause issues such as this.

DDR5 telemetry is read through the SMBUS from the SPDHUB. With an another app changing e.g., the SMBUS address or the index while HWiNFO is reading the data is likely to cause insane readouts such as this one. However, this can affect basically ANY of the monitoring values.

In most cases, the best place to start looking would be any other monitoring, CAM, RGB, etc. tools from third parties or the motherboard manufacturer.

[–] [email protected] 1 points 10 months ago

That is just GIGABYTE recycling the bios front-end across the multiple different SKUs.

Even if the Gen. 5 support would suddenly become available, it would make no difference unless the board is built for it, i.e., has the required hardware (Gen. 5 re-drivers).