CVS commit: src/sys/arch/x86/x86

["David H. Gutteridge" <gutteridge%netbsd.org@localhost>]

Module Name:    src
Committed By:   gutteridge
Date:           Tue Mar 12 02:26:16 UTC 2024

Modified Files:
        src/sys/arch/x86/x86: coretemp.c

Log Message:
coretemp.c: don't accept impossibly low TjMax values

r. 1.39 introduced a regression where instead of applying a reasonable
default maximum (as was done prior to that change), incorrect values
were accepted and applied, as failures to retrieve an expected MSR
value weren't accounted for.

Apply different logic for unexpectedly low vs. high maximums, with
distinct warnings for each. Also add another warning about a retrieval
failure right at the outset (which also just uses the default, then).

This change fundamentally doesn't address the fact that
__SHIFTOUT(msr, MSR_TEMP_TARGET_READOUT)
doesn't necessarily return a valid value. It just restores prior
behaviour, which is more reasonable than applying a zero value, which
started happening on some older hardware. (I infer this is most likely
an issue with dated generations of Intel hardware with this feature.)
The challenge is that this evidently isn't all documented properly
anywhere. Various "magic values" in this driver need further
investigation.

While here, also fix output so warnings are cleanly formatted, rather
than the slightly scrambled way they were appearing.

Tested on older Intel hardware I had on hand:
E7500 (now falls back to default 100 rather than 0)
E5540 (successfully retrieves 97, as before)
i5-3340M (successfully retrieves 105, as before)


To generate a diff of this commit:
cvs rdiff -u -r1.40 -r1.41 src/sys/arch/x86/x86/coretemp.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.