Impossible GPU VRM readings

Blyss Sarania

Honorable
Oct 4, 2013
10
0
10,510
So I had been watching how my GPU was doing (radeon 7870 GHZ edition) in HWINFO and I'm getting some impossible readings. The card was OC a good bit for these screenshots but it does it at stock too. Here in HWINFO you can see ludicrous readings in the "maximum" column. Also I included some screenshots from GPU z showing the min and max there too which don't seem right(the min anyway). The system is rock solid stable. No artifacts, no crashes. Even ran furmark for 12 hours solid with the OC speed(that's when I first noticed the suspicious readings). So of course I dropped back to stock but suspicious readings remain.

AMD FX 6300 @ 4.12GHZ
HIS Radeon HD 7870 2GB 256bit
AsRock 880 GM LE FX mobo
EVGA 500B 80 bronze plus PSU
Nothing else should be relevant. Oh it's on an uninterruptible power supply too.

Since the system is completely stable and the readings aren't just a little off, they are LUDICROUS(over 4 million amps for instance), I am inclined to ignore them. But still, what is going on here? Also not pictured is the readings from my PSU which are completely in spec on all rails.

1_zps1a5123af.png


3_zpsef13ebb5.png


2_zps021439f0.png
 
Solution


Something like that.

There's two different ways of doing device IO.

The first is known as Port-IO. Data is transferred along an isolated peripheral bus attached directly to the microprocessor from the CPU registers and vice versa. Port-IO does not collide with memory-IO (although it may share a common bus such as the FSB) and has its own address space.

Most devices expose their functionality through what's known as memory-mapped IO. Devices reserve addresses in the physical memory...


welcome to the world of memory mapped sensors. Just ignore them
 

Blyss Sarania

Honorable
Oct 4, 2013
10
0
10,510


Memory mapped as in you're saying the sensor readings are stored in a memory location which is getting overwritten by some unrelated data and then that's getting reported?

 


Something like that.

There's two different ways of doing device IO.

The first is known as Port-IO. Data is transferred along an isolated peripheral bus attached directly to the microprocessor from the CPU registers and vice versa. Port-IO does not collide with memory-IO (although it may share a common bus such as the FSB) and has its own address space.

Most devices expose their functionality through what's known as memory-mapped IO. Devices reserve addresses in the physical memory space (the same address space as the system memory) and IO requests made to these addresses are directed to the device instead of the system memory. This is the cause of the 640KiB barrier and the 3.5GiB barrier found in the original IBM PC and 32 bit non-PAE/non-remapping operating systems; sections of the physical memory space are reserved for hardware usage, which causes chunks of DRAM to be disabled.

Port-IO is complex, and has a lot of limitations. Since physical address spaces are no longer limited like they used to be, the industry has been moving in favor of memory-mapped IO. MMIO allows for simpler CPU and more robust drivers at the cost of only a slightly more complex memory subsystem.

Accesses made to these IO-mapped addresses aren't handled by a well behaved DRAM controller attached to well behaved DRAM modules. Instead, they're handled by the peripheral devices themselves. Attempting to poll a sensor too quickly may result in incorrect results as the ASIC has better things to do than respond to such requests. Many devices are often poorly documented, which makes writing one-size-fits-all monitoring tools incredibly difficult.
 
Solution

Blyss Sarania

Honorable
Oct 4, 2013
10
0
10,510
Understood. Like I said I figured there was no cause for alarm. You know if a 12v sensor was reporting 14 volts or 10 volts then that's one thing. But 59 kilovolts and 6 million amps? I don't think I would have ever even got to read the sensor should that be true. And probably things would have blown up lol.

Thanks for the info.