Checking CPU temperature

[Patrick O'Callaghan]

On Fri, 2008-06-13 at 16:24 -0400, Mike Williams wrote:
> On Fri, Jun 13, 2008 at 3:14 PM, Patrick O'Callaghan
> <pocallaghan at gmail.com> wrote:
> > On Fri, 2008-06-13 at 03:10 -0400, Ric Moore wrote:
> >> On Thu, 2008-06-12 at 10:27 -0430, Patrick O'Callaghan wrote:
> >> > On Thu, 2008-06-12 at 09:41 -0500, Aaron Konstam wrote:
> >> > > On Wed, 2008-06-11 at 18:05 -0430, Patrick O'Callaghan wrote:
> >> > > > On Wed, 2008-06-11 at 17:01 -0500, Aaron Konstam wrote:
> >> > > > > On Wed, 2008-06-11 at 16:06 +0100, Paul Smith wrote:
> >> > > > > > Dear All,
> >> > > > > >
> >> > > > > > In the output below, where should I look for the CPU temperature? The value
> >> > > > > >
> >> > > > > > CPU Temp:     -2.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = transistor
> >> > > > > >
> >> > > > > > seems unlikely. Or is -2.0°C realistic?
> >> > > > > >
> >> > > > > > Is there some other program to check the CPU temperature?
> >> > > > > >
> >> > > > > > Thanks in advance,
> >> > > > > >
> >> > > > > > Paul
> >> > > > > >
> >> > > >
> >> > > Actually he said: cat  /proc/acpi/thermal_zone/THRM/temperature
> >> > > would not work since it is supposed to be: THM
> >> >
> >> > Read the whole thing. He said he doesn't have anything
> >> > in /proc/acpi/thermal_zone, and in fact neither do I.
> >>
> >> Got the directory, as do you, and it's empty for me. Something else to
> >> fix! <sighs> Ric
> >
> > I have a suspicion that this might have to do with the coretemp kernel
> > module, which would explain why it only seems to happen on fairly recent
> > Intel cpus. The documentation
> > (/usr/share/doc/kernel-doc-2.6.25/Documentation/hwmon/coretemp) says:
> >
> >        Supported chips:
> >          * All Intel Core family
> >            Prefix: 'coretemp'
> >            CPUID: family 0x6, models 0xe, 0xf, 0x16, 0x17
> >            Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
> >                       Volume 3A: System Programming Guide
> >                       http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
> > 
> > If anyone is seeing the same problem on non-Intel cpus (not mobos), then
> > coretemp is not the culprit. Anyone?
> 
> Nothing in /proc/acpi/thermal_zone/ on the AMD system I'm using at the
> moment.  But, just like on my home system which is a pentium 4 the
> sensors data is in a different location.
> 
> [root at crick device]# cat /proc/cpuinfo |grep AMD
> vendor_id       : AuthenticAMD
> model name      : AMD Athlon(tm) Processor
> Linux crick.bio.whe.umb.edu 2.6.25.4-10.fc8 #1 SMP Thu May 22 23:34:09
> EDT 2008 i686 athlon i386 GNU/Linux
> acpid.i386                               1.0.6-5.fc8
> lm_sensors.i386                          2.10.6-1.fc8
> 
> [root at crick device]# ls -laR /proc/acpi/thermal_zone/
> /proc/acpi/thermal_zone/:
> total 0
> dr-xr-xr-x 2 root root 0 2008-06-13 16:02 .
> dr-xr-xr-x 8 root root 0 2008-06-10 13:53 ..
> 
> Meanwhile, just like on my pentium 4 at home there are sensor files elsewhere:
> 
> # ls /sys/class/hwmon/hwmon0/device
> alarms       fan1_div    fan3_alarm    in0_input  in2_alarm  in3_max
>  in5_beep   in6_min      temp1_max       temp3_beep
> beep_enable  fan1_input  fan3_beep     in0_max    in2_beep   in3_min
>  in5_input  modalias     temp1_max_hyst  temp3_input
> beep_mask    fan1_min    fan3_div      in0_min    in2_input  in4_alarm
>  in5_max    name         temp2_alarm     temp3_max
> bus          fan2_alarm  fan3_input    in1_alarm  in2_max    in4_beep
>  in5_min    power        temp2_beep      temp3_max_hyst
> cpu0_vid     fan2_beep   fan3_min      in1_beep   in2_min    in4_input
>  in6_alarm  subsystem    temp2_input     uevent
> driver       fan2_div    hwmon:hwmon0  in1_input  in3_alarm  in4_max
>  in6_beep   temp1_alarm  temp2_max       vrm
> fan1_alarm   fan2_input  in0_alarm     in1_max    in3_beep   in4_min
>  in6_input  temp1_beep   temp2_max_hyst
> fan1_beep    fan2_min    in0_beep      in1_min    in3_input  in5_alarm
>  in6_max    temp1_input  temp3_alarm
> 
> the values in the _input files correspond to the values displayed by
> the sensors program..

Well, what do you know, I get something similar:

# ls /sys/class/hwmon/hwmon[01]/device
/sys/class/hwmon/hwmon0/device:
driver  hwmon  modalias  name  power  subsystem  temp1_crit
temp1_crit_alarm  temp1_input  temp1_label  temp1_max  uevent

/sys/class/hwmon/hwmon1/device:
driver  hwmon  modalias  name  power  subsystem  temp1_crit
temp1_crit_alarm  temp1_input  temp1_label  temp1_max  uevent

with numbers in the temp* entries that look liked scaled equivalents of
what sensors says.

I don't know how much of this depends on the cpu and how much on the
chipset (i.e. the specific mobo), but it would be nice if there was some
kind of standard.

Something else: I keep ksensors running in the task bar to monitor
temperature, but it doesn't read the critical temperature correctly from
the kernel (it sets it to 70 when sensors says it's 80). It has to be
hand-configured to the correct value. I has some unnecessary anxiety
before I noticed this because the numbers go red when ksensors thinks
it's too hot, but that's another story :-)

poc