pmcputemp -temperature monitor

[davids45]

G'day 01micko,

Tried running your script (given a couple of posts earlier) to check cpu temperature outputs for this computer (HP low profile form desktop with "Intel vPro" sticker).

Result was:

# find /sys -type f -name 'temp*' -exec cat '{}' \;# find /sys -type f -name 'temp*' -exec cat '{}' \;
36000
Core 1
0
100000
100000
0
74000
74000
38000
Core 0
#

So it looks like my earlier higher temps (74C) with some Pups were for the 1 or 2 output whereas output 3 is probably the correct value for this CPU (38C).

Wheezy is giving 35C at the moment and all seems fine with pmcputemp.

Hope to check other Pups to see if I get 35 or 75.

David S.

Next try.....
In slacko-5.9.3, after some console entering and copying attempts (not really knowing what I'm doing), I saw and copied to geany:

# find /sys -type f -name 'temp*' -exec cat '{}' \;
80000
40000
Core 1
0
100000
100000
0
74000
74000
36000
Core 0

Are these the temperatures of various things/set-points for cores 0 and 1 (1 and 2 in layman's terms)? One attempt by me at entering your first script line did produce a list of parameters and related temperatures but I could not work out how to copy the urxvt output to geany with the mouse clicks without creating lots of extra gibberish on urxvt.

The Slacko task-bar icon is reading a steady 80C in pink but I suspect this is a maximum value set-point for core 1, not the actual core temperature of the cpu - if a dual core cpu actually has a single cpu value?

If it helps, hardinfo says I have:
-Processors-
Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz : 1596.00MHz
Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz : 1867.00MHz

David S.

Got lucky with mouse and urvxt. Is this what tells which is what temperature?

# find /sys -type f -name 'temp*'
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon/hwmon0/temp1_input
/sys/devices/platform/coretemp.0/temp3_input
/sys/devices/platform/coretemp.0/temp3_label
/sys/devices/platform/coretemp.0/temp2_crit_alarm
/sys/devices/platform/coretemp.0/temp2_crit
/sys/devices/platform/coretemp.0/temp3_crit
/sys/devices/platform/coretemp.0/temp3_crit_alarm
/sys/devices/platform/coretemp.0/temp2_max
/sys/devices/platform/coretemp.0/temp3_max
/sys/devices/platform/coretemp.0/temp2_input
/sys/devices/platform/coretemp.0/temp2_label

But which is the one (or two) that indicates how the core is running?

David S.

[666philb]

hi 01micko,

working for me in tahrpup and is also working on a dell laptop that tempiconsvg fails on.

one thing though, i feel the indicator turns red too quickly . i have a netbook that runs at 50-70degrees, tempicon covers this nicely going from green at 50 yellow late 60's and red probably approaching 80.

pmcputemp turns red in the late 50's which is a normal ok temp for this comp. and if it was actually overheating i wouldn't be getting the red warning cue as it's red all the time basically.

cheers

phil

[01micko]

David,

Try the 0.60 pet I posted going on your feedback. I think it will work for you. The out puts *should* be in one of the files named *input on the end. However, I found an old laptop that I have that stores it in a file named simply temp!

-----------------------------------------

Phil,

I'll consider bumping it up to about 70 or 75 before going into the red.

[davids45]

G'day 01micko,
Switching to .60 and using your scripts:

# find /sys -type f -name 'temp*'
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon/hwmon0/temp1_input
/sys/devices/platform/coretemp.0/temp3_input
/sys/devices/platform/coretemp.0/temp3_label
/sys/devices/platform/coretemp.0/temp2_crit_alarm
/sys/devices/platform/coretemp.0/temp2_crit
/sys/devices/platform/coretemp.0/temp3_crit
/sys/devices/platform/coretemp.0/temp3_crit_alarm
/sys/devices/platform/coretemp.0/temp2_max
/sys/devices/platform/coretemp.0/temp3_max
/sys/devices/platform/coretemp.0/temp2_input
/sys/devices/platform/coretemp.0/temp2_label
# find /sys -type f -name 'temp*' -exec cat '{}' \;
76000
33000
Core 1
0
100000
100000
0
74000
74000
37000
Core 0
#

The task-bar icon reads 76C and is pink, so is the first Core 1 value (=......../temp3_input)?

Noticing that newer kernel Pups seem to give/pick/run with the higher temperatures - the seventies, not the thirties.

David S.

[01micko]

Thanks for sticking with it David.

Now, I have 2 problematic laptops that store temperature in :

/sys/devices/virtual/thermal/thermal_zone0/temp

Both intel.

my AMD desktop has it in :

/sys/devices/pci0000:00/0000:00:18.3/temp1_input

.. however jamesbond said that one (or similar) fails for him so I test the read on it in the script and if it fails move on.

So now I have made a loop testing 3 more specific locations. Why they need to have ambiguous entries is beyond me but oh well, that's GNU!

Try this script, saving it to the text editor and making it executable, naming it 'test_temp.sh' (or something similar). Run it from CLI with ./test_temp.sh

Code: Select all

#!/bin/sh

find_func() {
	FILES="$1"
	for n in `echo $FILES`; do
		read p < $n
		if [ $? = 0 ];then
			FILE=$n
			break
		else
			continue
		fi
	done
}
cputempfunc() {
	
	for a in `find /sys/devices/virtual -type f -name 'temp'|sort` \
			`find /sys/devices/platform -type f -name 'temp*_input'|sort` \
			`find /sys/devices/pci* -type f -name 'temp*_input'|sort`
	do find_func "$a"
		[ -z "$FILE" ] && continue || break
	done
	if [ ! "$FILE" ];then echo "Failed to find file" && exit 1
	fi
	#echo "${FILE} is written to $TMP"
	#echo -n ${FILE} > $TMP/pmcputemprc
}
cputempfunc
echo "$FILE"
cat "$FILE"
 

It should output the location of the *input file and the temperature like so

Code: Select all

# ./test_temp.sh 
/sys/devices/pci0000:00/0000:00:18.3/temp1_input
37375

Cheers

[davids45]

G'day 01micko,
Just before I try your new script, here's the 0.60 output from an old Pup - Snowpup-015 with a 2.6.38.2 kernel.

sh-4.1# find /sys -type f -name 'temp*'
/sys/devices/platform/coretemp.0/temp1_max
/sys/devices/platform/coretemp.0/temp1_label
/sys/devices/platform/coretemp.0/temp1_crit_alarm
/sys/devices/platform/coretemp.0/temp1_input
/sys/devices/platform/coretemp.0/temp1_crit
/sys/devices/platform/coretemp.1/temp1_max
/sys/devices/platform/coretemp.1/temp1_label
/sys/devices/platform/coretemp.1/temp1_crit_alarm
/sys/devices/platform/coretemp.1/temp1_input
/sys/devices/platform/coretemp.1/temp1_crit
sh-4.1# find /sys -type f -name 'temp*' -exec cat '{}' \;
74000
Core 0
0
35000
100000
74000
Core 1
0
36000
100000
sh-4.1#

Now it's all 'temp1_' with no 'temp2_' or 'temp3_' as per some of the newer kernels/Pups.
And it still seems like either a "74" or "35" to pick from.
Reading down from the above list, the first "....temp1_input" = 35000 for core 0 ("_label") and 36000 for Core 1 (next "_label" in the list).
The "74000" values line up with the "temp1_max lines".

It almost makes sense to me at last .

And 'Happy April Fools' Day' (also my wedding anniversary) .

David S.

[davids45]

G'day 01micko,
Here is a collection of responses from your test_temp script.

SnowPup015 result
sh-4.1# ./test_temp.sh
/sys/devices/platform/coretemp.0/temp1_input
37000
sh-4.1#

Dpup Wheezy-3.5.2.11
# ./test_temp.sh
/sys/devices/platform/coretemp.0/temp2_input
35000
#

UnicornPup-6.0
# cd /mnt/sda5/Temp
# ./test_temp.sh
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon/hwmon0/temp1_input
80000
#

Slacko-5.9.3 (kernel-3.4.94)
# cd /mnt/sda5/Temp
# ./test_temp.sh
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon/hwmon0/temp1_input
79500
#

I'm suspicious of the slacko and unicorn results somehow being "_max" values not the desired operating temp values.

Has anyone with a quadcore processor tried the scripts - could/should there be a set of outputs for each core?

A 'richman's' version of cputemp could show temperatures for each processor (rich men don't have single core cpus, so I'm told, and have monitors with big enough task-bars to show several temp icons )

David S.

[davids45]

Another response with the 0.60 pet and scripts:

# find /sys -type f -name 'temp*' -exec cat '{}' \;# find /sys -type f -name 'temp*'
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon/hwmon0/temp1_input
/sys/devices/platform/coretemp.0/temp3_input
/sys/devices/platform/coretemp.0/temp3_label
/sys/devices/platform/coretemp.0/temp2_crit_alarm
/sys/devices/platform/coretemp.0/temp2_crit
/sys/devices/platform/coretemp.0/temp3_crit
/sys/devices/platform/coretemp.0/temp3_crit_alarm
/sys/devices/platform/coretemp.0/temp2_max
/sys/devices/platform/coretemp.0/temp3_max
/sys/devices/platform/coretemp.0/temp2_input
/sys/devices/platform/coretemp.0/temp2_label
# find /sys -type f -name 'temp*' -exec cat '{}' \;
65000
38000
Core 1
0
100000
100000
0
74000
74000
35000
Core 0
#

Precise Pup-5.7.1 (kernel 3.09.11 - 0.60 icon shows 78C pink)
# ./test_temp.sh
/sys/devices/platform/coretemp.0/temp2_input
36000
#

The Precise task-bar icon (the pink 78C) does not match the script result (36C) for this Pup. The '78C' looks like it's the core 0 "temp2_max" (74000 but later rose to 78C and is now 80C- is the _max a variable) ?

David S.

[01micko]

Hi David,

That is a strange result as my script is supposed to search /sys/devices/platform before /sys/devices/pci*. In fact that was the main change from what is in the pmcputemp-0.60 program now.

Lets just concentrate on slacko-593 or Unicorn, you choose, since either of those gives a similar result.

I just want a test of these commands:

find /sys/devices/platform -type f -name 'temp*_input'

and

find /sys/devices/platform -type f -name 'temp*_input' -exec cat '{}' \;

-------------------------------------

As for the Precise temp, the pmcputemp prog is giving the wrong reading; The other higher one may possibly video chip temp. With the newer script that should get fixed, but I don't want to release anything until we get to the bottom of this other problem.

Cheers

[OscarTalks]

Just to confirm that compile and run in Precise 5.7.1 now all works OK. I have been testing version 0.60 in a number of machines. Works fine in:-
E-machines intel atom netbook
Old Dell Inspiron 2200 Pentium M laptop
E-System 3086 Celeron laptop
Toshiba Satellite L40-14N laptop
Slightly less old Dell Vostro Pentium dual-core desktop
Compaq Presario SR1709 AMD Sempron / ATI desktop
Mesh Computers (Matrix Inspire?) AMD Athlon desktop
Unidentified SiS chipset Pentium 4 with HT desktop

On 3 of my machines the script does not find the temperature file. These are:-
Dell Dimension P4 with HT desktop
HP Compaq D530 Small Form Factor P4 with HT desktop
Dell Optiplex GX520 Small Form Factor P4 with HT desktop
In each of these there appears to be no file of that name under /sys and Radky's PupSysInfo also reports

Code: Select all

▶—— CPU Temperature ——◀

Sensor status is not available, or required kernel drivers are not loaded.

so I don't know it that means that the sensor is broken or what.
Anyway, a solution to this is not essential for me as these machines all appear to run OK but I just thought I would document my findings in case they are helpful to anyone.

[01micko]

Thanks Oscar

Glad we sorted that smashing issue

FWIW, I have a P4 that doesn't work with any temperature program so maybe it is a peculiarity of P4's?

Cheers

[jamesbond]

Confirm that it works here too. I will upload this to the repo and perhaps basesfs too since its very small indeed.

[SFR]

I'll consider bumping it up to about 70 or 75 before going into the red.

How about using temp_high & temp_crit to calculate when to switch to other color(s)?

For instance, my Intel-i3 has temp_high=80 & temp_crit=90 and AMD-c60 has temp_high=70 & temp_crit=105 (or 115 or 120, depending on kernel version ; temp_high is constant, though).

Since temp_crit doesn't seem to be reliable, perhaps simple:
[ current_temp >= temp_high-10 ] && yellow
[ current_temp >= temp_high ] && red
(or sth like that) would be good enough..?

Oh, btw, pmcputemp works fine for me on both i3 and c60, thanks!

EDIT: I meant temp_max, not temp_high.

Greetings!

[01micko]

Hi James,

Well, I'm not sure its ready for "prime time", ie: inclusion in main distro, simply because there is still an issue with finding the right sensor re davids45's problems. In the repo shouldn't be a problem but I would wait a day or 2 until I adjust the scale. I do have a lappy that happily runs at 58° and shows red, so I will be bumping it up quite a bit. Some intels aren't critical until 105° .. my program quits at 99.

When I originally wrote tempicon I had a very hot nvidia board, actually the same box I'm typing on now, but I ditched that board for a gigabyte. When compiling it would approach 100° fairly quickly and with sustained compiles (like the kernel or seamonkey/firefox) would invariably quit. So I would monitor temp and adjust cpu scaling to get it running flat out without reaching critical mass .

Also, fatdog needs a doinst.sh to add it to Startup (and run it as the pinstall.sh does now), so people aren't left wondering WTF just happened when they install the thing.

Cheers!

------------------

@SFR.. having enough fun finding the actual temp.. so we'll keep it poor for now.

[davids45]

G'day 01micko,

Tried your two lines from your post in a terminal in slacko-5.9.3.
Neither produced any output, just a new line starting with #.

Below is the text I copied for checking, and the responses from urxvt:

from recent post: for checking:
find /sys/devices/platform -type f -name 'temp*_input'

find /sys/devices/platform -type f -name 'temp*_input' -exec cat '{}' \;

terminal output in slacko-5.9.3 (reading a pink 80):

# find /sys/devices/platform -type f -name 'temp*_input'
#
# find /sys/devices/platform -type f -name 'temp*_input' -exec cat '{}' \;
#

next I tried terminal output in dpup wheezy-3.5.2
# find /sys/devices/platform -type f -name 'temp*_input'
/sys/devices/platform/coretemp.0/temp3_input
/sys/devices/platform/coretemp.0/temp2_input
# find /sys/devices/platform -type f -name 'temp*_input' -exec cat '{}' \;
37000
38000
#

unicornpup-6.0 gave same blank outputs as slacko-5.9.3 and reading the same pink 80C.

David S.

[01micko]

Thanks David,

Just try once more in slacko593 or unicorn without /devices/platform

Code: Select all

find /sys -type f -name 'temp*_input'

Code: Select all

find /sys -type f -name 'temp*_input' -exec cat '{}' \; 

Thanks.

[jamesbond]

Thanks Mick, I will wait until the minor bugs as weeded out then. (I will report them as I find them too). I can supply the doinst.sh no problem.

[charlie6]

Hi 01micko,
thanks this temp monitor !
will give it a try !
here is the (already nice translated yes, yes !!... i'm not kidding ..!!) french locale somewhat tuned

nb: tar.gz compacted attachment of .mo and .po files

Best regards, Charlie

oops...! reuploaded with .po file

[charlie6]

Hi again,
here running an intel PIV trunk with k10temp module loaded (reported by lsmod - BUT hardinfo's sensors section is empty --> maybe not any temp sensor present on this trunk ???);

i have compiled pmcputemp on whezzy-3.5.2.5 and get the following:

sh-3.00# pmcputemp
Failed to find file
Impossible de créer le fichier de configuration.
sh-3.00#

only an empty /root/.config/pmcputemp folder is created;

and

sh-3.00# exec /usr/bin/pmcputemp.sh

causes terminals hang up when pressing ENTER key ...

nothing appears in the tray bar

Charlie

[01micko]

Hi charlie,

First, thanks for a real fr translation . It is uploaded to the git repository and will be in the next package.

Second, please try the commands I posted for davids45 here and report.

Much obliged.

PS: I mentioned in an earlier post I might use hardinfo's methods to find the temp sensor data, but it fails miserably on a laptop I have where this one works, so I decided against. Perhaps we can make it work for you, or not. We'll see. I also have a P4 which doesn't work at all. One thing, if your chip is intel, most likely coretemp should load, definitely not k10temp (though it is possible something else on the board wants it). The script should load coretemp if possible, else it quits.