Wrong rdmsr temperature/voltage/clock for Core 2 CPUs about libcpuid HOT 3 OPEN

Thank you for reporting this.
The RAW MSR dump shows worrying things, e.g. the min multiplier is clearly stated as 9, in reg 0x0ce. But as I see the docs, the number there may be MHz*100, not multiplier. What is the idle frequency (at min multiplier), can you test?
By multiplier 6 it would be 1600 MHz, which I see as rather high, but possible.

We definitely don't decode IA32_PERF_STATUS (0x198) properly. The 0x06 0x1e there is undocumented ("model-specific, do not assume anything"), and our comment there is "the high byte seems to be the multiplier, the low byte is 0". This probably looked right on another CPU, but it's not correct. If this decoding can be trusted it, the 0x06 0x1e would mean "600 MHz, 1.18V", so at least the voltage seems correct.

The temperature computation is wrong because MSR_TEMPERATURE_TARGET (0x1a2) is basically empty - the thermal trip temperature is read as 0°C, instead of a reasonable value like 100°C. If it were 100°C, then the computation would be close to correct (37°C or 42°C, depending on whether TCC is 100 or 105°C).

from libcpuid.

According to CPU-Z, minimum CPU multiplier is 6 and maximum CPU multiplier is 9:

MSR_PLATFORM_INFO is not documented for Intel Core 2 processor family and for Intel Xeon processors based on Intel Core microarchitecture (DisplayFamily 06H, DisplayModel 0FH):

Not sure how to properly detect if this MSR is supported.
This register seems valid starting Intel Core ix CPUs.

I found this for coreboot in get_fsb_tsc(): they enumerate all display family and models.
In Intel® 64 and IA-32 Architectures Software Developer’s Manual, there is table 35-1 (CPUID Signature Values of DisplayFamily_DisplayModel).
For AMD CPUs, it is easier because display family is increasing generation after generation, unlike Intel; implementing such checks in libcpuid will require some work.

Intel Core 2 CPU family is 16 years old, meaning fewer and fewer people are still using these CPUs nowaday.
I understand all decoded values from MSRs are wrong with your CPU (it is in the name itself: they are model specific), but I do not want to invest time to fix that, sorry.

from libcpuid.