cpu temperature readings

[Robert Elz <kre%munnari.OZ.AU@localhost>]

Hi all.

I'm currently running HEAD from about June 14.   My system has been
having what appear to be temperature related issues (those are not
the point of this e-mail).

As part of attempting to deal with (or diagnose) what is happening
there, I switched the CPU frequency to go slower (slower CPU, less
heat).   I was expecting a minor temperature reduction.

Instead, when I did (initially

sysctl -w machdep.cpu.frequency.target=2500

(reducing from the apparent max, 3401) the temps dropped (almost
instantly) from upper 30's (C) to low 40's, down to the high teens
or very low 20's.

That's in a room with room temperature in the low 20's at the time.

I switched the target (and actual reported running frequency) to
3400 (just leaving off the "turbo boost" "1") which made no
difference.

Today (still using 3400 as the frequency) I have seen reported
CPU temperatures as low as 8 degrees C (in a room with ambient
temps that never would have dropped below 20 - with the A/C
running fairly hard).   Since I don't believe my motherboard,
processor, or cooler, have refrigeration capabilities, that's
somewhat remarkable.

I have just turned "turbo boost" back on (freq 3401) and the
temp readings now are more normal, upper 20's (nicely above
the ambient air temp, as one would normally expect) to mid
30's, with occasional excursions into the low 50's when a core
gets temporarily busy.

Has anyone else seen anything like this?

Details of the CPU are appended - at least the basic model
info from "cpuctl idenify 0", if knowing the (huge) set of
feature bit settings would be useful (or some particular ones)
I can supply those later.

And while I am here, I currently see only the CPU core temps in
envstat, but the BIOS can see much more.  I suspect one of these
"not configured" is the culprit.

[     1.025183] Intel 600 Series PCH-H I2C 0 (miscellaneous serial bus, revision 0x11) at pci0 dev 21 function 0 not configured
[     1.025183] Intel 600 Series PCH-H SPI (FLASH) (miscellaneous serial bus, revision 0x11) at pci0 dev 31 function 5 not configured

Those might be being "not configured" either because NetBSD currently
doesn't support them, or perhaps more likely, something is missing from
my custom kernel config.  If it is the latter, and anyone knows what I
should be including, I'd appreciate a hint!

There's a bunch of other stuff not configured (including the WiFi,
which I know we do not currently support) but I doubt that any of
that is related to missing sensor devices (the BIOS can see fan
speeds, motherboard temp,  (and voltages, but those might be done
differently).

Thanks,

kre

jacaranda# cpuctl identify 0
cpu0: highest basic info 00000020
cpu0: highest extended info 80000008
cpu0: "12th Gen Intel(R) Core(TM) i9-12900KS"
cpu0: Intel 12th gen Core (Alder Lake) (686-class), 3417.60 MHz
cpu0: CPU base freq 3400000000 Hz
cpu0: CPU max freq 5500000000 Hz
cpu0: TSC freq CPUID 3417600000 Hz
cpu0: family 0x6 model 0x97 stepping 0x2 (id 0x90672)
[....]
cpu0: SEF highest subleaf 00000001
cpu0: SEF-subleaf1-eax 0x401c10<AVXVNNI,FZLRMS,FSRSB,FSRCS,HRESET>
cpu0: Power Management features: 0x100<ITSC>
cpu0: Perfmon-eax 0x8300805<VERSION=0x5,GPCounter=0x8,GPBitwidth=0x30>
cpu0: Perfmon-eax 0x8300805<Vectorlen=0x8>
cpu0: Perfmon-edx 0x8604<FixedFunc=0x4,FFBitwidth=0x30,ANYTHREADDEPR>
cpu0: Hybrid: Core type 40, Native Model ID 0000001
cpu0: microcode version 0x16, platform ID 1


(That's running its supplied microdode - I disabled the microcode
updates, as the issue I'm seeing appeared soon after the most recent
microcode update was installed.   But clearly that was irrelevant,
as not doing the update has made no difference, so I will be enabling
that again soon).   I am also currently running with hyperthreading
disabled (which seems to have been a change that is keeping my
system running OK) - the 8 "economy" cores have also been disabled
(but not by me) - the processor, or BIOS, does that sometimes (and
always has) - they will return after a full power off (as in, removing
power from the power supply - nothing less works).  Having those disabled
has not made any difference to the original problem (though enabling them
might have made it worse - but that was from a single experiment under
non-controlled circumstances, so really means nothing.)