Solved Temperature anomaly (not weather related :) )

This may belong in hardware, or maybe not ... administrator(s) please feel free to move it if needed.

I have a small form factor Celeron based NUC machine running 13.2. While preparing to movee forward from 13.2, I suddenly had a display system failure. While looking into that I found that the failure was indeed in the NUC, not in the display itself. Then I found that the NUC seemed quite warm, almost to what I would call hot, but not quite there yet. I SSH'ed my way into the NUC and tried to measure some temperatures. After considerable guesswork and trickery, I found that if I loaded coretemp module and tried to measure I got 90.0C for each of the 4 cpu's. At that temperature I would almost expect molten cpu to be running all over the table. On a lark, I tried amdtemp after unloading coretemp and got number ranging from 0.0C to 88.9C, but not remaining constant ... they seemed to vary purely at random. Again on a lark, I loaded BOTH amdtemp and coretemp and thistime I got consistent numbers in the range 40.0C to 49.something C and they remained quite stable. While I consider it rather too warm, at least it should not be cpu melting temperatures. But that all raises the question about why neither module alone gave useful numbers and how the pair together gave what seemed to be reasonable ones? I am about to strip that machine down to bare metal and start over but wanted to see if anyone had any ideas about further investigation before I cover all the tracks. I am about out of ideas.

Thanks,
QG
 
First, @drhowarddfine, I quite agree with your observation ... :)

Secondly, @Emiron, I agree that I have an Intel processor, but that does not explain why I need BOTH the Intel AND the AMD modules loaded at the same time to get a meaningful or useful result. That still makes no sense to me. Since it is, indeed, an Intel processor, I would have expected the Intel module alone to work well, and the AMD one being added to interfere rather than assist.

QG
 
I found that if I loaded coretemp module and tried to measure I got 90.0C for each of the 4 cpu's.
Is this not credible? I mean you had a system failure. This temperature is abnormal, but you may have some dust around your processor or a fan which dysfunctions.

It's possible (I didn't search) that this specific processor isn't covered by the coretemp module, but why look to the AMD side? This has no sense to me.
 
While this is possible, as you point out especially after a failure, I found it not to match with the case temperature (admittedly measured only by my hand, but I would not have held on to that case very long if the 90.0C temperatures inside were real). As to why I tried both modules at once, it was a combination of ingredients ... In the heat of battle, I neglected to unload the Intel module before loading the AMD module, and following the principle of serendipity (sometimes things simply DO work) I "discovered" the apparent working recipe as measured by the reality of not holding on to a 90C object. Fact is, I have now separately validated the 45C range by further case measurement and find it believable. But I still curious as to the "why" it works that way and if maybe there is some further documentation that might be of some value here. Or an opportunity for a development of sorts. Lots of good and useful inventions have come from accidents like this.
 
You confuse the temperature of the processor (or its socket) with what you can sense with your finger. You touched the heat sink, not the processor itself. Indeed, a temperature above 60°C can't be held on your skin exceeding a few seconds, but that wasn't the real processor temperature.
 
1. amdtemp is completely irrelevent, since you have an intel cpu; do not load amdtemp, that is a red herring
2. load coretemp ONLY, such that the following command only lists coretemp:-

# kldstat | grep -E 'coretemp|amdtemp'
3 1 0xffffffff82142000 36c8 coretemp.ko

3. sysctl hw.acpi.thermal.tz0.temperature will return the acpi thermal zone zero temp, typically cpu package
4. sysctl dev.cpu | grep temperature - will return the on-die temperature registers of each core
5. install the program 'hwstat' with pkg install hwstat to obtain a nicely formatted summary like this:-

# hwstat
Current Unit
[Coretemp]
CPU0: 50.0 C
CPU1: 50.0 C
CPU2: 38.0 C
CPU3: 38.0 C

[ACPI Thermal]
tz0: 49.1 C

5. A value of 40-50 C is typical and perfectly OK. A value of 90 C is unlikely to ever occur unless your cpu is limping along under thermal throttling just prior to shutdown. But check cpu utilisation is not stuck on 100% due to some cpu hog process using top or htop.

6. vacuum cpu fan and case dust; renew heatsink compound; check fan speed
 
I had an Intel NUC that shut down a few times because of thermal events and then it appears to have cooked itself - it was new-ish so don't think it had time for a dust build up.

As others are saying 40-50 degrees is normal, nearer 100 deg. C there should be thermal cut-outs before anything bad happens.

I have some fanless Protectli machines that are usually warm to the touch and feel hot when they are busy (they show around 50 deg. C)
 
Well, blackbird9 and @ ricjardtoohey2, I have taken you both up on the advice. While previously I was not using hwstat but rather sysctl -a and then searching via grep, hwstat sure does make it easier and nicer. I carefully unloaded amdtemp and checked what was left loaded. It looked good, so I installed hwstat and ran it. Now all looks good with temperatures in reasonable ranges. SSH with X forwarding seems to be working, just local video is not displaying either under X or in console mode. This is a bright shiny new NUC, just out of the factory sealed box, so I do not suspect any buildup, but yeah, that is the second greatest enemy of small systems. Don't ask about the first greatest :).

I now come to the conclusion that the video circuitry, and maybe a little more circuitry, is dead in infancy, although it worked for a little while. Ah well, it may yet work for headless duties, of which I have a few in mind.

I am still confused about why loading both modules seemed to work, but that may be a self answering question, the operative word being "seemed". :(

I am mostly satisfied now, and so will mark this solved. Thanks for the suggestions!!!!

QG
 
After considerable guesswork and trickery, I found that if I loaded coretemp module and tried to measure I got 90.0C for each of the 4 cpu's. At that temperature I would almost expect molten cpu to be running all over the table.
My i5-8400H can hit that occasionally on a laptop but I think SpeedShift or something hardware-side knows to start lowering frequency to not go beyond that. Iirc 90-100C is what Intel advertises as safe for a lot of CPUs.
 
My i5-8400H can hit that occasionally on a laptop but I think SpeedShift or something hardware-side knows to start lowering frequency to not go beyond that. Iirc 90-100C is what Intel advertises as safe for a lot of CPUs.
To explain this further, I think it's hardware P states or something but once it gets to 90C (nearly instantly from a stress-test), CPU frequency starts dropping from Turbo frequency slowly, while temps still remain at 90C. It seems like the CPU has a safety feature to prevent damage starting at 90C, and Intel advertises max Tjunction (assuming the fancy-term for the whole CPU in-general :p) temp at 100C. On FreeBSD 14.1 I have dev.hwpstate_intel.0.epp=0 and it as-expected locks my CPU freq, so if the temp/throttle tech is related to EPP or hwpstate, I'm using it and it seemingly works fine (Intel mobile CPU isn't able to get hot-enough to cause damage on FreeBSD).

I feel that a NUC would be designed with heat in-mind (TV box set-ups or cramped spaces) with the same throttle logic. I'd find out what the name of the tech that does the throttling is, see if your CPU has it, and run a stress test with 0.5s-interval updates on CPU frequency and temp to see if it works (I don't see why it wouldn't work, but not sure what would happen if it doesn't).
 
Back
Top