Bug 437637

You don't happen to be running into this on a thinkpad are you?

Yup.

Thinkpad X60.

Here is output from 'strace sensors':

[root@localhost ~]# strace sensors
execve("/usr/bin/sensors", ["sensors"], [/* 24 vars */]) = 0
brk(0)                                  = 0x8622000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=98064, ...}) = 0
mmap2(NULL, 98064, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f7d000
close(3)                                = 0
open("/usr/lib/libsensors.so.4", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2600\266\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=53244, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f7c000
mmap2(0xb61000, 50892, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb61000
mmap2(0xb6d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE,
3, 0xc) = 0xb6d000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p7\230\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1796316, ...}) = 0
mmap2(0x96d000, 1504848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x96d000
mmap2(0xad7000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16a) = 0xad7000
mmap2(0xada000, 9808, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0xada000
close(3)                                = 0
open("/lib/libm.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`$\256\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=211128, ...}) = 0
mmap2(0xadf000, 163968, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xadf000
mmap2(0xb06000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE,
3, 0x26) = 0xb06000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f7b000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f7b6c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xad7000, 8192, PROT_READ)     = 0
mprotect(0xb06000, 4096, PROT_READ)     = 0
mprotect(0x969000, 4096, PROT_READ)     = 0
munmap(0xb7f7d000, 98064)               = 0
brk(0)                                  = 0x8622000
brk(0x8643000)                          = 0x8643000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=77970672, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d7b000
close(3)                                = 0
stat64("/sys", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open("/sys/class/i2c-adapter",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
getdents(3, /* 3 entries */, 4096)      = 52
open("/sys/class/i2c-adapter/i2c-0/name", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f94000
read(4, "SMBus I801 adapter at 18e0\n", 4096) = 27
close(4)                                = 0
munmap(0xb7f94000, 4096)                = 0
getdents(3, /* 0 entries */, 4096)      = 0
close(3)                                = 0
open("/sys/class/hwmon", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getdents(3, /* 6 entries */, 4096)      = 112
readlink("/sys/class/hwmon/hwmon0/device", 0xbf892a1a, 254) = -1 ENOENT (No such
file or directory)
close(3)                                = 0
write(2, "sensors_init: Kernel interface e"..., 37sensors_init: Kernel interface
error
) = 37
exit_group(1)                           = ?
[root@localhost ~]# 

Here is 'ls /sys/class/hwmon/hwmon0':
[root@localhost hwmon0]# ls
name   subsystem   temp1_input  temp2_input
power  temp1_crit  temp2_crit   uevent
[root@localhost hwmon0]# 

and

[root@localhost hwmon]# ls -l *
lrwxrwxrwx 1 root root 0 2008-03-15 15:07 hwmon0 ->
../../devices/virtual/hwmon/hwmon0
lrwxrwxrwx 1 root root 0 2008-03-15 15:07 hwmon1 ->
../../devices/platform/thinkpad_hwmon/hwmon/hwmon1
lrwxrwxrwx 1 root root 0 2008-03-15 15:07 hwmon2 ->
../../devices/platform/coretemp.0/hwmon/hwmon2
lrwxrwxrwx 1 root root 0 2008-03-15 15:07 hwmon3 ->
../../devices/platform/coretemp.1/hwmon/hwmon3
[root@localhost hwmon]# 

Seems to be a 'device' in hwmon1:

[root@localhost hwmon]# ls -l hwmon1/*
lrwxrwxrwx 1 root root    0 2008-03-15 17:22 hwmon1/device ->
../../../thinkpad_hwmon
lrwxrwxrwx 1 root root    0 2008-03-15 15:07 hwmon1/subsystem ->
../../../../../class/hwmon
-rw-r--r-- 1 root root 4096 2008-03-15 15:07 hwmon1/uevent

hwmon1/power:
total 0
-rw-r--r-- 1 root root 4096 2008-03-15 17:23 wakeup
[root@localhost hwmon]# 

I thought this is the same bug as 436767, but looking at the strace its different.

Jean (added to the CC),

I believe this is triggered by the hwmon interface of the new acpi thermal zone
code, which should work with 3.0.1 because of your fix for:
http://lm-sensors.org/ticket/2260

Which is this commit:
http://lm-sensors.org/changeset/5093

However the readlink in this function:

static int sensors_add_hwmon_device(const char *path, const char *classdev)
{
        char linkpath[NAME_MAX];
        char device[NAME_MAX], *device_p;
        int dev_len, err;
        (void)classdev; /* hide warning */

        snprintf(linkpath, NAME_MAX, "%s/device", path);
        dev_len = readlink(linkpath, device, NAME_MAX - 1);
        if (dev_len < 0)
                return -SENSORS_ERR_KERNEL;
        device[dev_len] = '\0';
        device_p = strrchr(device, '/') + 1;
 
        /* The attributes we want might be those of the hwmon class device,
           or those of the device itself. */
        err = sensors_read_one_sysfs_chip(linkpath, device_p, path);
        if (err == 0)
                err = sensors_read_one_sysfs_chip(linkpath, device_p, linkpath)
        if (err < 0)
                return err;
        return 0;
}

Is failing as there is no device pointer for the hwmon class entry made by the
acpi thermal zone driver, note that the hwmon0 entry in /sys/class/hwmon points to:
/sys/devices/virtual/hwmon/hwmon0

And appearantly hwmon class entries of a virtual device, do not have a device
pointer. Notice that the results of the readlink are only used to pass as second
argument to sensors_read_one_sysfs_chip(), the second argument of
sensors_read_one_sysfs_chip(), only gets used by sensors_read_one_sysfs_chip()
to determine the bus and address of the sensor, passing in something like
"virtual" in the scenario when there is no device link should work.

Another problem here is that linkpath, which now does not exists, gets passed as
first param to sensors_read_one_sysfs_chip(), linkpath can simply be replaced in
this case by path, as the first param to sensors_read_one_sysfs_chip() is used
to look for a "subsystem" link and then fallback to a "sub" link in that path,
and sensors_read_one_sysfs_chip() will still succeed if no subsystem nor sub
links are found, in which case when it does not recognize its second param as
representing a certain subsys type, it will assume platform/ISA as type for the
sensor, which sounds reasonable.

I'll attach a patch implementing this, and do a scratch build of a new
lm_sensors with this fix in.

Created attachment 298182 [details]
PATCH fixing libsensors failing on hwmon class entries without a device link

Created attachment 298183 [details]
PATCH: check if a device is a PCI device before assuming its a platform device.

Jean,

While looking into this I also noticed that sensors_read_one_sysfs_chip(),
currently, if there is no subsytem or sub link in device_path, will recognize a
PCI device as being an ISA device, even if dev_name does match a PCI device,
because if there is no subsys link found it assumes a platform device, before
checking for a PCI device.

This simple patch fixes this (theoretical, all pci drivers should have a subsys
link, given when they were introduced) problem.

Let me know if its ok to commit this fix to svn.

Tom,

Here is a sratch build of a new version of lm_sensors which hopefully fixes this:
http://koji.fedoraproject.org/koji/taskinfo?taskID=518228

Can you give this a try and see if it fixes things for you please?

(In reply to comment #6)
> Created an attachment (id=298183) [edit]
> PATCH: check if a device is a PCI device before assuming its a platform
> device.
> 
> Jean,
> 
> While looking into this I also noticed that sensors_read_one_sysfs_chip(),
> currently, if there is no subsytem or sub link in device_path, will recognize
> a PCI device as being an ISA device, even if dev_name does match a PCI device,
> because if there is no subsys link found it assumes a platform device, before
> checking for a PCI device.
> 
> This simple patch fixes this (theoretical, all pci drivers should have a
> subsys link, given when they were introduced) problem.
> 
> Let me know if its ok to commit this fix to svn.

Yes, your patch is correct and should be committed to SVN. The platform case
acts as a fallback solution so it must be last in the list. Thanks for spotting
this bug. That being said, it probably won't change anything in practice.

Problem might go beyond ACPI thermal zone and virtual devices... See:
http://bugzilla.kernel.org/show_bug.cgi?id=10259

It seems that something changed in sysfs between 2.6.25-rc5-git3 and -git4. I'll
investigate later this afternoon.

(In reply to comment #9)
> Problem might go beyond ACPI thermal zone and virtual devices... See:
> http://bugzilla.kernel.org/show_bug.cgi?id=10259

In fact this is the exact same bug. The reporter simply got confused by the
renumbering of the hwmon class devices caused by the new generic thermal driver.

(In reply to comment #10)
> (In reply to comment #9)
> > Problem might go beyond ACPI thermal zone and virtual devices... See:
> > http://bugzilla.kernel.org/show_bug.cgi?id=10259
> 
> In fact this is the exact same bug. The reporter simply got confused by the
> renumbering of the hwmon class devices caused by the new generic thermal driver.
> 

Then my patch should fix things, Tom any chance you can provide us with some
feedback on this?

IOW can you install:
http://koji.fedoraproject.org/koji/taskinfo?taskID=518228

And let us know if it fixes things?

Thanks for the quick fix.  [Sorry for the slow response.... ]

I installed lm_sensors-3.0.1-5.fc9.i386.rpm and ran "sensors":

[root@localhost Downloads]# sensors
thinkpad-isa-0000
Adapter: ISA adapter
fan1:       3008 RPM
temp1:       +42.0°C                                    
temp2:       +32.0°C                                    
ERROR: Can't get value of subfeature temp3_input: Can't read
temp3:        +0.0°C                                    
temp4:       +42.0°C                                    
temp5:       +16.0°C                                    
ERROR: Can't get value of subfeature temp6_input: Can't read
temp6:        +0.0°C                                    
temp7:       +16.0°C                                    
ERROR: Can't get value of subfeature temp8_input: Can't read
temp8:        +0.0°C                                    
temp9:       +34.0°C                                    
temp10:      +36.0°C                                    
ERROR: Can't get value of subfeature temp11_input: Can't read
temp11:       +0.0°C                                    
ERROR: Can't get value of subfeature temp12_input: Can't read
temp12:       +0.0°C                                    
ERROR: Can't get value of subfeature temp13_input: Can't read
temp13:       +0.0°C                                    
ERROR: Can't get value of subfeature temp14_input: Can't read
temp14:       +0.0°C                                    
ERROR: Can't get value of subfeature temp15_input: Can't read
temp15:       +0.0°C                                    
ERROR: Can't get value of subfeature temp16_input: Can't read
temp16:       +0.0°C                                    

coretemp-isa-0000
Adapter: ISA adapter
Core 0:      +45.0°C  (crit = +100.0°C)                  

coretemp-isa-0001
Adapter: ISA adapter
Core 1:      +44.0°C  (crit = +100.0°C)                  

[root@localhost Downloads]# 

and

[root@localhost Downloads]# service lm_sensors restart
Stopping lm_sensors:                                       [  OK  ]
Starting lm_sensors: loading module coretemp               [  OK  ]
[root@localhost Downloads]# 

so looks like this fixes it.

(In reply to comment #5)
> Created an attachment (id=298182) [edit]
> PATCH fixing libsensors failing on hwmon class entries without a device link

Hans, your patch doesn't work. It lets libsensors go past the missing "device"
link, however in sensors_read_one_sysfs_chip(), when reading the "subsystem"
link, it gets "hwmon" for the new thermal zone device, and this isn't supported,
so the device gets ignored. While this is an improvement compared to the current
situation (at least other hwmon devices are still displayed) that's probably not
what you hoped for.

There are a number of design decisions around the new thermal zone device which
I do not like. I'll start a discussion thread about this. Depending on the
outcast, libsensors may or may not need additional tweaks. Until this is sorted
out, I think that we should simply let libsensors ignore hwmon entries with no
device link. Ignoring unsupported stuff is the right thing to do anyway,
otherwise we end up fixing libsensors in a rush each time something changes on
the kernel side.

Ah, the hwmon class dir does have a subsystem link, I thought it didn't have any
and thus we would end up calling the thermalzone hwmon entry an ISA device at
address 0.

Hi, as Hans suggested that all hwmon attributes for generic thermal driver go 
to one hwmonX entry, the hwmonX registered by the Generic Thermal driver is a 
virtual devices, thus no device link available.
And hwmonX contains the sys I/F for several thermal zones, while each of them 
has a device node.
I'm not quite clear about why a device link is mandatory.
But I don't see the benefit of a device link for hwmonX registered by the 
generic thermal driver. IMO, it can't be used to do anything. So we should 
either ignore the check of a device link, or ingore the hwmonX with the 
name "thermal_sys_class". :)

I still believe that having one hwmon entry with all the attributes of the
thermal zone driver there is the best interface, having one hwmon class per zone
doesn't make sense.

If this means that there won't be a device link and libsensors needs to be
updated to handle this, so be it.

I do not share your views that one hwmon entry with all the attributes of the
thermal zone driver is the best choice. I'm sorry that I did not notice your
proposal in this direction earlier. I think that it would make more sense to
have one hwmon entry for each "user" of the generic thermal zone driver, i.e.
one hwmon entry for all ACPI thermal zones, and one more hwmon entry for each
other type of thermal zones.

That being said, doing this would probably not help with the problem at hand, as
each ACPI thermal zone has it's own device. They have a common parent, which
could be used as the hwmon's device link... Not sure if this could be
implemented easily though. Anyway, let's discuss this on the mailing lists,
bugzilla isn't the place.

(In reply to comment #17)
> I do not share your views that one hwmon entry with all the attributes of the
> thermal zone driver is the best choice. I'm sorry that I did not notice your
> proposal in this direction earlier. I think that it would make more sense to
> have one hwmon entry for each "user" of the generic thermal zone driver, i.e.
> one hwmon entry for all ACPI thermal zones, and one more hwmon entry for each
> other type of thermal zones.
> 

+1,

> I didn't know there could be multiple drivers exporting thermal zones.
> Anyway, let's discuss this on the mailing lists,
> bugzilla isn't the place.

+1, See you on the lists.

Crap,

Notice that "I didn't know there could be multiple drivers exporting thermal
zones" in comment #18 is not text being replied to but me motivating my +1.

Created attachment 298270 [details]
PATCH: Recognize and properly handle virtual hwmon devices

This is my attempt to add support for virtual devices to lm-sensors 3.0.1.
Tested successfully on two different systems. Hans, can you please review and
comment? Note that I am not yet sure if this can be the final fix, depends on
the conclusion of our discussion on the mailing lists, and others things I want
to investigate.

Same issue for a Tyan Tomcat K8E running the x86_64 branch of "rawhide".

(In reply to comment #20)
> Created an attachment (id=298270) [edit]
> PATCH: Recognize and properly handle virtual hwmon devices
> 
> This is my attempt to add support for virtual devices to lm-sensors 3.0.1.
> Tested successfully on two different systems. Hans, can you please review and
> comment? Note that I am not yet sure if this can be the final fix, depends on
> the conclusion of our discussion on the mailing lists, and others things I want
> to investigate.
> 

Ok, here is my review:

1) I'm worried that we may one day get multiple instances of a virtual device,
then we need todo something smarter with chip->addr, as the prefix will be the
same and if we keep addr at 0 for all virtual devices 2 instances of a virtual
device will get the same result from sensors_snprintf_chip_name(), and many
libsensors using apps use sensors_snprintf_chip_name() /
sensors_parse_chip_name() to store / retrieve chip name structures. But it might
be best to leave fixing this until we actually run into this problem.

2) You've accidentally included a local Makefile change in the patch

3) Since you (correctly) bump the API define, you really need to document both
the bump and what changed in CHANGES

New scratch-build with Jean's version of the patch:
http://koji.fedoraproject.org/koji/taskinfo?taskID=520591

Tom and/or Joachim, can you give this a test spin?

Tom, this should give you one more additional device listed in your sensors
command output (the acpi thermal zone's temperature readings).

OK.  Installed (had to use '--force' since the version # didn't change).

Here is the output from 'sensors'.  Believe the
'thermal_sys_class-virtual/Virtual device' is new:

[root@localhost Downloads]# sensors
thermal_sys_class-virtual-0
Adapter: Virtual device
temp1:       +28.0°C  (crit = +127.0°C)                  
temp2:       +30.0°C  (crit = +97.0°C)                  

thinkpad-isa-0000
Adapter: ISA adapter
fan1:       3009 RPM
temp1:       +47.0°C                                    
temp2:       +33.0°C                                    
ERROR: Can't get value of subfeature temp3_input: Can't read
temp3:        +0.0°C                                    
temp4:       +44.0°C                                    
temp5:       +18.0°C                                    
ERROR: Can't get value of subfeature temp6_input: Can't read
temp6:        +0.0°C                                    
temp7:       +18.0°C                                    
ERROR: Can't get value of subfeature temp8_input: Can't read
temp8:        +0.0°C                                    
temp9:       +34.0°C                                    
temp10:      +37.0°C                                    
ERROR: Can't get value of subfeature temp11_input: Can't read
temp11:       +0.0°C                                    
ERROR: Can't get value of subfeature temp12_input: Can't read
temp12:       +0.0°C                                    
ERROR: Can't get value of subfeature temp13_input: Can't read
temp13:       +0.0°C                                    
ERROR: Can't get value of subfeature temp14_input: Can't read
temp14:       +0.0°C                                    
ERROR: Can't get value of subfeature temp15_input: Can't read
temp15:       +0.0°C                                    
ERROR: Can't get value of subfeature temp16_input: Can't read
temp16:       +0.0°C                                    

coretemp-isa-0000
Adapter: ISA adapter
Core 0:      +48.0°C  (crit = +100.0°C)                  

coretemp-isa-0001
Adapter: ISA adapter
Core 1:      +48.0°C  (crit = +100.0°C)                  

[root@localhost Downloads]# 

(In reply to comment #22)
> 1) I'm worried that we may one day get multiple instances of a virtual device,
> then we need todo something smarter with chip->addr, as the prefix will be the
> same and if we keep addr at 0 for all virtual devices 2 instances of a virtual
> device will get the same result from sensors_snprintf_chip_name(), and many
> libsensors using apps use sensors_snprintf_chip_name() /
> sensors_parse_chip_name() to store / retrieve chip name structures. But it
> might be best to leave fixing this until we actually run into this problem.

I agree, it's really only a quick hack at the moment. We need to give it some
more thought, but I am waiting to see what will happen on the kernel side first.
I do not want libsensors to attribute arbitrary sequence numbers (it wouldn't be
stable across reboots etc.) so the "address" must come from the kernel somehow.

> 2) You've accidentally included a local Makefile change in the patch

Damn. It happens to me all the time :( Sorry about this.

> 3) Since you (correctly) bump the API define, you really need to document both
> the bump and what changed in CHANGES

I agree. It might even deserve a separate file under doc/developers/.

lm_sensors-3.0.1-5.fc9 works for me:

thermal_sys_class-virtual-0
Adapter: Virtual device
temp1:       +40.0°C  (crit = +100.0°C)                  

k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp:  +51.0°C

[I have neither tailored a custom /etc/sensors3.conf nor have I run
sensors-detect.]

3.0.1-5.fc9 fixed a problem I was having.
Previously I was getting:
Starting lm_sensors: loading module i2c-amd756 lm90 w83627hf sensors_init:
Kernel interface error
After upgrading I got:
Starting lm_sensors: loading module i2c-amd756 lm90 w83627h[  OK  ]

Another data point:

I had the same problem as reported in comment #27, on installed F9 Beta.  
Updating to lm_sensors-3.0.1-5.fc9.x86_64.rpm fixed it for me as well.  Updated 
only this package, not a general update.

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

[root@localhost tmp]# service lm_sensors start
Starting lm_sensors: loading module i2c-i801 w83793 coretem[  OK  ]
[root@localhost tmp]# sensors
w83793-i2c-0-2f
Adapter: SMBus I801 adapter at 1100
VCoreA:      +1.20 V  (min =  +0.92 V, max =  +1.49 V)
VCoreB:      +1.20 V  (min =  +0.92 V, max =  +1.49 V)
Vtt:         +1.08 V  (min =  +1.08 V, max =  +1.33 V)   ALARM
in3:         +0.51 V  (min =  +0.38 V, max =  +0.69 V)
in4:         +1.46 V  (min =  +1.34 V, max =  +1.65 V)
+3.3V:       +3.30 V  (min =  +2.96 V, max =  +3.63 V)
+12V:       +12.00 V  (min = +10.75 V, max = +13.25 V)
+5V:         +5.05 V  (min =  +4.64 V, max =  +5.65 V)
5VSB:        +5.07 V  (min =  +4.64 V, max =  +5.65 V)
VBAT:        +3.22 V  (min =  +2.99 V, max =  +3.66 V)
fan1:       3678 RPM  (min =  712 RPM)
fan2:       3658 RPM  (min =  712 RPM)
fan3:       3562 RPM  (min =  712 RPM)
fan4:       3802 RPM  (min =  712 RPM)
fan5:       2890 RPM  (min =  712 RPM)
fan6:          0 RPM  (min =  712 RPM)  ALARM
fan7:          0 RPM  (min =  712 RPM)  ALARM
fan8:          0 RPM  (min =  712 RPM)  ALARM
fan9:          0 RPM  (min =  712 RPM)  ALARM
fan10:         0 RPM  (min =  712 RPM)  ALARM
CPU1 Temp:   +23.0°C  (high = +70.0°C, hyst = +65.0°C)  sensor = Intel PECI
CPU2 Temp:   +19.0°C  (high = +70.0°C, hyst = +65.0°C)  sensor = Intel PECI
temp3:      -128.0°C  (high = +70.0°C, hyst = +65.0°C)  sensor = Intel PECI
temp4:      -128.0°C  (high = +70.0°C, hyst = +65.0°C)  sensor = Intel PECI
temp5:       +26.0°C  (high = +50.0°C, hyst = +45.0°C)  sensor = thermistor
beep_enable:disabled

coretemp-isa-0000
Adapter: ISA adapter
Core 0:      +31.0°C  (high = +76.0°C, crit = +100.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Core 1:      +16.0°C  (high = +76.0°C, crit = +100.0°C)

coretemp-isa-0002
Adapter: ISA adapter
Core 2:      +34.0°C  (high = +76.0°C, crit = +100.0°C)

coretemp-isa-0003
Adapter: ISA adapter
Core 3:      +16.0°C  (high = +76.0°C, crit = +100.0°C)

coretemp-isa-0004
Adapter: ISA adapter
Core 4:      +30.0°C  (high = +76.0°C, crit = +100.0°C)

coretemp-isa-0005
Adapter: ISA adapter
Core 5:      +29.0°C  (high = +76.0°C, crit = +100.0°C)

coretemp-isa-0006
Adapter: ISA adapter
Core 6:      +27.0°C  (high = +76.0°C, crit = +100.0°C)

coretemp-isa-0007
Adapter: ISA adapter
Core 7:      +29.0°C  (high = +76.0°C, crit = +100.0°C)

This is "working for me".

Close?

(In reply to comment #29)
> This is "working for me".
> 
> Close?

Erm, yes its working with the scratch build from koji, but I didn't do a real
build yet (waiting for possible another solution from upstream). I've just
started a real build, and will request for F-9 inclusion of this.

Patch has been applied upstream:
http://www.lm-sensors.org/changeset/5176

(In reply to comment #31)
> Patch has been applied upstream:
> http://www.lm-sensors.org/changeset/5176

Will this (working) version of lm_sensors make it into the Fedora 9 release?

(In reply to comment #32)
> (In reply to comment #31)
> > Patch has been applied upstream:
> > http://www.lm-sensors.org/changeset/5176
> 
> Will this (working) version of lm_sensors make it into the Fedora 9 release?
> 

I've requested rel-eng to include it and they haven't objected, so yes.