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@xxxxxxxxx> 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@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@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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
