[SOLVED] High to critical CPU temp, despite low usage

[ren09]

Hi all, have also an i7 with nvidia-gpu 7years old Laptop. Fan-speed is not available, because it's speed is only controled by the temp-sensors.
As it is an older one, you can open the back easy and have a look. The GPU is not a different card but a chip on the mainboard. There is only one fan and one heatpipe for both CPU and GPU. Past seven years I found only little dust, a bit on the heatpipe inside the fanhousing and some on the wings of the fan nearly not to see but with a paintbrush removeable. This downed the temp for circa 2 degree. Normal idle-temp is around 49Celsius in Power-save-modus. Performance-mode brings idle 54C (outside 20C). So long this sounds all equal normal.
In mint 18.3 cinnamon the temp is 4C lower, in mint20.1 cinnamon with kernel 5.4.081 as above, but with kernel 5.4.082 or older than 5.4.054 2C more hot. So cinnamon is not a power-saver!
I have installed "thinkfan" where you can set the fan-speed easy in 7 steps. The fan starts now earlier and reaches the highest speed also earlier, all set one step higher.
In /sys/class/hwmon/hwmon2/templ_crit you can see two warning temps, should 85C and 100C for shut-down. This is ok.
At an another laptop with only 2cores both temps are 105C, but could not find where to set this. It usually works around 35C, so it doesn't matter but for me this is not fine. You cannot compare a 2core-temp with a 4core-temp.

[motoryzen]

You could try cpupower-gui ( found in software manager) and see if setting it to "on demand" ( as long as your kernel is 5.8 or newer..it will allow you to select that particular setting) and see if that helps.

in mint20.1 cinnamon with kernel 5.4.081 as above, but with kernel 5.4.082 or older than 5.4.054 2C more hot. So cinnamon is not a power-saver!

To me that sounds like you're blaming the newer version of Cinnamon for the problem instead of the kernel version. *shrugs* Who told you that cinnamon is a light weight/and or power-saver type of desktop environment? It was never designed to be that from my understanding of using it the past 11 years straight. It's designed to be a fully featured modern windows replacement.

1. Please post the results of inxi -Fxxxrz ( step 5 of how to get help link that is right above the message posting window) ... so we can see what we're working it with under the hood. Not all i7 cpu's are the same. Some run slightly warmer than others regardless of be it only idle temps or full load temps. Not necessarily blaming the cpu here, but we need more details. Otherwise there is much room for time wasting speculation.

2. Given the laptop is 7 years old, when was the last time you opened it up completely enough to remove that cpu ( and it might be a both cpu AND onboard gpu cooling solution) to clean off old dried up thermal paste and applied some good new thermal paste?

[SMG]

1. Please post the results of inxi -Fxxxrz ( step 5 of how to get help link that is right above the message posting window) ... so we can see what we're working it with under the hood. Not all i7 cpu's are the same. Some run slightly warmer than others regardless of be it only idle temps or full load temps. Not necessarily blaming the cpu here, but we need more details. Otherwise there is much room for time wasting speculation.

If ren09 would like help, then ren09 should create a new thread with that info.

We are discussing GreenIsBest's issues in this thread and I presumed ren09's post to be information that GreenIsBest might be able to use rather than a request for help.

It gets too confusing when discussing multiple computers in the same thread which is why we request users create separate threads for their issues.

[GreenIsBest]

Hi all, have also an i7 with nvidia-gpu 7years old Laptop. Fan-speed is not available, because it's speed is only controled by the temp-sensors.

Ah. Guess that explains why the /inxi -Fxz reports N/A under the fan details. The rest of your description does match most of the numbers/experience I get on my side, down to the surprisingly clean insides. Good to know you have similar temperatures, seems that mine is not really overheating that much.
The thermal paste should still be good since is only 1-1,5 years old, so again, either the cooling is insuficient, or these temperatures really are the normal.

Cinnamon is definetly no power-saver, wich it (kinda) proudly advertises, as it was meant to be a "comfort-desktop" of sorts. Whenever power/performance is wanted, the 1st advice is usually "try the Xfce"; something wich I too have considered even before these temperature shenenigans appeared.
Cinnamon on the other hand seems to be a full featured noob-friendly alternative to the Windows desktop experience. Wich it briliantly does, even if that means sacrificing some efficiency. Given the humor that goes around Linux and keeping with the food/flavors theme, I'm surprised it wasn't called the "Butter" desktop, under the tagline "I can't believe it's not Windows", and would double as a pun for "better".

The GPU is not a different card but a chip on the mainboard.

You point something that I never even considered. My computer claims it has 2 GPU's; the Nvidia one, and a "Intel integrated graphics". The Intel GPU seems to give it away on it's namesake, but the Nvidia one might be a separate board/chip/thingy; the casing sure has the room for it. I can switch between the two from cinnamon's taskbar, but the temperatures are pretty much the same.

Will add this "thinkfan" to the list of things to learn about or experiment.

[ren09]

My computer claims it has 2 GPU's; the Nvidia one, and a "Intel integrated graphics". The Intel GPU seems to give it away on it's namesake, but the Nvidia one might be a separate board/chip/thingy

Hi, that is the reason I told to open the back and have a look. As the laptop is 12 years old this should be done easy, only some screws. May be at that time that there is a seperate card with passive cooling, but for me the overheating with heavy load for both, CPU and GPU, sounds like the GPU is a chip on the mainboard and one cooling=heatpipe for both.
If the nvidia-GPU is off=Power-save-Modus it is really not to see for the system, you can see this with inxi, only intel integrated-GPU. ( Don't update nvidia in Power-save-modus, will create severe problems) But! in Performance-modus or ON-Demand(works now first time for older GPUs) both GPUs are working, nvidia more or less for the output. So intel-GPU is not off. => More power consumption, more heat.
Do you know in the meantime the set critical-temp and shut-off-temp?
waiting for news ren

[GreenIsBest]

Had a about 1h of spare time, wich was enough to check some of the suggestions.
First went to the BIOS screen to check for Fan options.
The only option related to the Fan is "Silent mode--- Disabled/Auto", wich in my machine is set to Auto, and according to the description, it simply means that the fan is free to start blasting as loud as it wants whenever it sees fit, as opposed to a "keep it quiet" behavior.

What really surprised me while on the BIOS screen, was that the fan was blasting non-stop, and venting quite a lot of heat.
And once I exited the BIOS and booted Linux Mint, the venting and the heat actually went DOWN. Yes, down.
How does a BIOS, the most basic and barebones computer interface, was somehow generating more heat and requiring more cooling, that a running full-fledged modern GUI-based OS (i.e. Linux Mint Cinnamon). How is that even electronically possible?
This blows my mind on so many levels, and makes this whole temperature thing ever more bizzare.

The only other thing in the BIOS that migh be worth mentioning, is that my "UEFI Boot" option is disabled, as it was by default when I purchased the machine all the way back in August/September 2011 (happy 10th bootday by the way).
Still learning this whole UEFI thing, but from what I've learned so far, one of the differences between UEFI and BIOS is the size of disk/file/something that can be boot. Given how I'm running Mint 20.1, I'm guessing this "UEFI Disabled" isn't interfering that much (if at all); but I'm happy to be corrected on this.

All other BIOS settings are unrelated. No remote booting, no BIOS access over network, Boot order priority, bla bla bla.

As for the journalctl -r -b -1 command recomended by senjoz, it returned 2 reports, for the 2 crashes I can remember.
They are so small, that I think I can even put them right here. Both reports are exacly the same, the latest of them reads as such:

Code: Select all

Minty systemd-journald[375]: Journal stopped
Sep 25 16:02:20 Minty systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Sep 25 16:02:20 Minty systemd-shutdown[1]: Syncing filesystems and block devices.
Sep 25 16:02:19 Minty systemd[1]: Shutting down.
Sep 25 16:02:19 Minty systemd[1]: Reached target Power-Off.
Sep 25 16:02:19 Minty systemd[1]: Finished Power-Off.
Sep 25 16:02:19 Minty systemd[1]: systemd-poweroff.service: Succeeded.
Sep 25 16:02:19 Minty systemd[1]: Reached target Final Step.
Sep 25 16:02:19 Minty systemd[1]: Finished Shuts down the "live" preinstalled system cleanly.
Sep 25 16:02:19 Minty systemd[1]: casper.service: Succeeded.
Sep 25 16:02:19 Minty systemd[1]: Starting Shuts down the "live" preinstalled system cleanly...
Sep 25 16:02:19 Minty systemd[1]: Reached target Shutdown.
Sep 25 16:02:19 Minty systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.
Sep 25 16:02:19 Minty systemd[1]: lvm2-monitor.service: Succeeded.
Sep 25 16:02:19 Minty systemd[1]: Stopped Remount Root and Kernel File Systems.
Sep 25 16:02:19 Minty systemd[1]: systemd-remount-fs.service: Succeeded.
Sep 25 16:02:19 Minty systemd[1]: Reached target Unmount All Filesystems.
Sep 25 16:02:19 Minty systemd[1]: Deactivated swap /swapfile.
Sep 25 16:02:19 Minty systemd[1]: swapfile.swap: Succeeded.
Sep 25 16:02:19 Minty systemd[1]: Stopped Create System Users.
Sep 25 16:02:19 Minty systemd[1]: systemd-sysusers.service: Succeeded.
Sep 25 16:02:19 Minty systemd[1]: Stopped Create Static Device Nodes in /dev.
Sep 25 16:02:19 Minty systemd[1]: systemd-tmpfiles-setup-dev.service: Succeeded.
Sep 25 16:02:19 Minty systemd[1]: Stopping Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling...
Sep 25 16:02:19 Minty systemd[1]: Stopped target Local File Systems (Pre).
Sep 25 16:02:19 Minty systemd[1]: Unmounted /run/timeshift/backup.
Sep 25 16:02:19 Minty systemd[1]: run-timeshift-backup.mount: Succeeded.
Sep 25 16:02:19 Minty systemd[1]: Unmounting /run/timeshift/backup...
Sep 25 16:02:19 Minty systemd[1]: Stopped target Local File Systems.
Sep 25 16:02:19 Minty systemd[1]: Stopped Create Volatile Files and Directories.
Sep 25 16:02:19 Minty systemd[1]: systemd-tmpfiles-setup.service: Succeeded.
Sep 25 16:02:19 Minty systemd[1]: Stopped Update UTMP about System Boot/Shutdown.
Sep 25 16:02:19 Minty systemd[1]: systemd-update-utmp.service: Succeeded.
Sep 25 16:02:19 Minty systemd[1]: Stopped Network Time Synchronization.
Sep 25 16:02:19 Minty systemd[1]: systemd-timesyncd.service: Succeeded.

Reading these 2 journal entries did ring a bell, reminding me what exacly I was doing when it crashed. If I remember it correctly, I was trying to disable Samba and Warpinator, since I don't use them and don't like having sharing/LAN/cloud/sync gubbins running on my device.
On at least one of the crashes, I distinctly remember screwing up and uninstalling Samba altogether (trough software manager, while checking what exacly Samba was made of since it didn't show on the startup menu). This resulted in Celluloid also being uninstalled (???) and at this point I figured I had screwed up something and used timeshift to return to a previous state.

So on hindsight, the actual crashes themselves may have been related to this uninstall, like some important file gone missing (the guides specifically warn against uninstalling default apps) regardless of the crash-warning screen saying it was CPU-temperature related.
Either way, the temperature remains at the levels I posted already, even on the clean state before any of this foolish tinkering.

At this point my spare time ran out, so this is all I can try out and update on the thread.

[rene]

It's standard that CPU power management is disabled while in the BIOS setup; that the CPU runs full tilt whether it's actually doing something useful or not. BIOS/UEFI will not be related here.

I note the thread's fairly long by now and as far as I've read you still haven't tested the thing I suggested in the very first reply. Even if possibly not expected, a bug in that area should still be ruled out at minimum given that it used to be an issue/bug on your hardware. Highly suggest you do as advised there; if it doesn't help that's important information.

[senjoz]

As for the journalctl -r -b -1 command recomended by senjoz, it returned 2 reports, for the 2 crashes I can remember.
They are so small, that I think I can even put them right here. Both reports are exacly the same, the latest of them reads as such:

That cannot be a complete output of journalctl -rb -1. You should scroll the output with the down arrow. Please use second suggested command, journalctl -rb -1 | nc termbin.com 9999, and post the url address you get at the end. You should do that at first boot after an unexpected shutdown.

Regards, Jože

[SMG]

Given how I'm running Mint 20.1, I'm guessing this "UEFI Disabled" isn't interfering that much (if at all); but I'm happy to be corrected on this.

No, it would not be interfering. It just means your computer is running Legacy BIOS mode.

[ren09]

Hi, have seen the disassembly of an Samsung RV511, some more screews than thought (At my lenovo Z570 only 7 screews and all relevant is to see). The GPU sits directly aside the CPU, one heatpipe and one fan only. So it is easy to put the heatpipe, but heat concentrates on one point. Silicium is a hot-conductor, more heat less resistance more current more heat ...means it is selfdestructive- many gamers experienced this with smoking-up the CPU. It's useful to shutdown by reaching temp-max. You have kernel 5.4.084, for my experience 5.4.081 runs cooler.
Good news: now even in power-save-mode inxi shows the second GPU and correct: driver N/A =>no nvidia-staff update in this mode!
Also On-demand works, let the GPU slow down if not needed. 1 year before the system crashed when switching to on-demand, last half year then only cinnamon. I would try this mode for powersaving.
ren

[GreenIsBest]

Right, so tried rene's advice of adding the intel_pstate=disable parameter, and confirmed it was indeed applied trought the cat /proc/cmdline
On idle, it did absolutely nothing, but it did make a difference when doing tasks. I didn't run the full stress-test again, but I did try out the same "test tasks" I had done before learning about the actual stress-tes app. The temperature was 2-6 ºC lower when using the kernel parameter, at no noticeable difference in speed.
From what little I dug up, my take was that paremeter limits the amount of power (and thus heat) that goes trough the CPU; is this correct?

Then I went to run the journalctl command again, properly and with the termbin part. And here I noticed something weird.
Acording to senjoz, the journalctl -rb -1 shows the logs from the last boot where there was a unexpected shutdown (in reverse order). And according to the output, it was when I last used the machine to try the advices given here... wich wasn't when I had the crashes occur.
So I shutdown the device (menu > quit> shutdown) waited 5 minutes and booted up again. Ran the journalctl -rb -1 again, and the output was of today, 5 minutes ago.
Then I shutdown the machine (again), wrote down the time (hh:mm:ss) I clicked the "Quit> shutdown" button. Waited 1 hour, booted again, and ran journalctl -rb -1 again. The output was of the exact time I ordered the shutdown.

Does this mean every single shutdown is being logged as a "unexpected shutdown"?
Either way, here is the url for the termbin: <removed>
That specific URL is from the FIRST journalctl I ran today (before the purposefull shutdown>>boot), so it refers to the previous time I used the machine, BUT NOT to the dates when it crashed due to (reportedly) overheating.

[SMG]

Then I went to run the journalctl command again, properly and with the termbin part. And here I noticed something weird.
Acording to senjoz, the journalctl -rb -1 shows the logs from the last boot where there was a unexpected shutdown (in reverse order). And according to the output, it was when I last used the machine to try the advices given here... wich wasn't when I had the crashes occur.

That code is not to specifically get information from a crash. It is to get information from the prior boot cycle (that is the -1 part).

If you run the command journalctl --list-boots | tail -n 10, that will list the last ten boots you did with your computer. The first number in each line corresponds to the last part in the command senjoz gave you.

Your current boot cycle is 0; the prior boot cycle is -1; the one before that is -2, etcetera. If you can tell, based on the time stamp for the boot cycle, which one had the crash, you can get the information just for the "crash" boot cycle by substituting the correct number for the -1 part of the command senjoz gave you.

[rene]

Right, so tried rene's advice of adding the intel_pstate=disable parameter, and confirmed it was indeed applied trought the cat /proc/cmdline
On idle, it did absolutely nothing, but it did make a difference when doing tasks. I didn't run the full stress-test again, but I did try out the same "test tasks" I had done before learning about the actual stress-tes app. The temperature was 2-6 ºC lower when using the kernel parameter, at no noticeable difference in speed.
From what little I dug up, my take was that paremeter limits the amount of power (and thus heat) that goes trough the CPU; is this correct?

Well, specifically intel_pstate=disable disables the specific Intel (sandybridge+) CPU frequency scaling governor; would have it retreat to the the more generic ACPI frequency scaling governor. Former as said at some point had a fairly specific bug that I encountered immediately on googling for your system so that seemed to really want a try at least.

Given that it didn't really work as such but still did something it seems the ACPI governor's likely just a bit more conservative, and that it would seem likely a hardware issue. The thread's by now just a tad too long to fully review but is it perhaps a banal case of that new-ish thermal paste application having gone a bit poorly?

I suppose you will (with the Intel governor, i.e., with the kernel parameter removed again) see a load-time temp reduction if you do

Code: Select all

echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo

(possibly to the same levels as with that intel_pstate=disable) but that should again not influence idle state and is in any case not a "proper" solution of anything.

Frankly, for now not otherwise too sure; given that it did something it just seems that your CPU is getting too hot when boosting; can in turn not think of much other than hardware issue...

[senjoz]

The thread's by now just a tad too long to fully review but is it perhaps a banal case of that new-ish thermal paste application having gone a bit poorly?

That may be true. That can explain throttling CPU frequency below processor base frequency during stress test. Also, differences in core temperatures are quite high during stress test.

On the other hand, stress tests did not cause unexpected shutdowns. OP did not mention how frequent are unexpected shutdowns and what he is doing on the machine at those occasions.

Regards, Jože

[ren09]

On the other hand, stress tests did not cause unexpected shutdowns.

May be that there are different designed boards like the one the video showed, but if it is like this, the CPU sits at the end of the heatpipe and only one cm aside the GPU nearer to the fan. Means: the GPU heavy working will prevent the CPU-cooling, even can rise their temp because GPU-temp is allowed to be higher (126C). Would be helpful if - Greenisbest - remembers: are the shutdowns more due to heavy load of the GPU than that of the CPU???
For this special board a thermal paste like Kreafol KP99 or Artic MX4 will be needed. Greenisbest can ask the one who put it, what kind of paste was (is still) used.
ren

[senjoz]

GPU-temp is allowed to be higher (126C)

Huh, 126 ºC? Is it possible? GreenIsBest should really check what he is doing on the machine when unexpected shutdowns occur.

Regards, Jože

[ren09]

Huh, 126 ºC? Is it possible?

really high, nvidia Prime shows this!
Failure to show the original picture. It reads:
NVIDIA X Server Settings
Thermal Sensor Information
ID: 0
Target: GPU
Provider: GPU internal
Slowdown Temp: 127°C
Temperature: 54C
May be it is a bug and shall be 127°F, perhaps a °F-user can have a look in his system. This 127 is not to change. Aside is a graph in green showing correctly 54°C, but above without the °, no mistake from me. Around 65°C it changes to yellow, so possible to slow down at 89°C. Don' t know which number the machine uses.
ren

[GreenIsBest]

Well, I can't find the logs; even tried checking every one in the /var/logs folder. Does using Timeshift to rollback also revert the logs? Because if yes, then the logs really don't exist anymore; as I will explain.

OP did not mention how frequent are unexpected shutdowns and what he is doing on the machine at those occasions.

I really didn't. I remember writing it down and tought I had mentioned here... oh wait, I did, just very poorly .
As best as I can remember, this is what happened:

There where only 2 crashes.
I was browsing the Software Manager, to see what exacly I had installed from Samba and Warpinator; I planed to deactivate them as I have no use for file sharing.
The first crash happened during the browsing of the packages in Software Manager; just by browsing it. Waited a few minutes to let it cool (saw the crash-screen mentioned "critical", "CPU" and "temperature"), then booted again.
While trying to figure how to disable Samba, I remember I did end up uninstalling it; wich also caused Celluloid to be uninstalled for some reason.
Went to Synaptic to check the damages (wich packages had been uninstalled), and the 2nd crash happened during the browsing.
At this point I figured I had screwed up something, remembered I had just broken the "don't uninstall default apps" advice; and figured the crashes had probably been caused due to this screw up (completely missing the point that the 1st crash happened before the uninstall).
I used Timeshift to revert the system back to before fiddling with Samba. Only after the Timeshift I remembered that the 1st crash actually happend before the damages, so it couldn't be due to the uninstall.

This is when I used the /sensors command (knowing the ), noticed the idle temperatures and saw how high they got during use. That's when I decided to "stop doing things" and make this thread to seek help/advice.
Of course, without the logs, can never know exacly what happened. Are they really gone due to the Timeshift, or am'I just looking them wrong?

Either way, I agree that

the thread's by now just a tad too long to fully review

. And it seems safe to assume that whatever is causing this problem, is likely not Mint's "fault". Even if it is, I should give the hardware a fix anyway; if anything to get that problem out of the way.
Perhaps this thread is due to be closed?

Everything, the stress-test and the kernel parameter, seems to indicate bad-cooling of the hardware; and while the thermal paste is recent, the fan sure is not.
The insides of the laptop are indeed exacly as rene09 describes; all of the "heat makers" are cramped on the same corner of the casing, with 1 single fan cooling everything. The GPU definetly "shares" some heat with the CPU.
I can confirm the vent is clean and the CPU thermal paste is still there; good or bad I don't know. If the GPU has it's own special paste, then it has never been changed since purchase.

[SMG]

Does using Timeshift to rollback also revert the logs?

If you use the default settings of Timeshift, it will revert the logs to the time the snapshot was taken.

Perhaps this thread is due to be closed?

You, as the first person to post in the thread, would be the one to mark it closed, if you feel it is time to do so. You can do that by going to your very first post in this thread, click the pencil icon, and add [CLOSED] to the title so others know you are no longer seeking help on this issue.

[GreenIsBest]

Well, it is official now: the high temperature is definetely not related to Linux Mint. A clean install of Windows 10, and a factory reset to Windows 7 (still have it) still results in abnormaly high idle temperatures. Nothing lost, as the windowses still had their own leftover-partition. Physical hardware problem it is.
At least it never crashed again, so as bad as it is, it is at least bellow the critical threshold.

Thank you all for the support and suggestions, if anything for helping me learn more about Linux Mint and get a better hang of it, wich will come in handy once the heat problem is fixed or move to another machine.
Will edit my first post, to leave this conclusion/resolution in plain sight. Will wait ~24 hours, in case anyone wants to add something, then close this thread.