Bug 249428

Created attachment 159866 [details]
Output of 'sensors-detect' for 'PR440FX' mainboard

Created attachment 159867 [details]
Modules loaded for 'PR440FX' mainboard

Hi,

Short intro: I'm a community co-maintainer of lm_sensors and also the author of
various hwmon drivers.

Yes i2c-isa no longer exists (luckily as it was a gross hack). This is probably
causing problems with the somewhat old Fedora lm_sensors startup scripts.

A new version of lm_sensors currently is available in updates-testing which
should fix this.

Can you please install this, as follows:
yum update --enablerepo=updates-testing lm_sensors

And then try again, that should solve your problem.

Also notice that the lm_sensors init script doesn't really start anything, it
just loads the necessary modules. The sure way to see if your sensors are
working is to type: "sensors" and check the output. I think that with the
current version of lm_sensors things are still fine, but the initscript doesn't
know howto detect the new driver, and thus finds no sensors.

(In reply to comment #3)
The version reported above actually is the one you are referring to.
Btw, how can you claim that 'i2c-isa' does not exist anymore? It is
still present in the modules directory of the latest update kernel.
In the past it was sufficient to modprobe 'lm78.ko', 'i2c-isa.ko',
and 'sensors.ko' to obtain a working command 'sensors' [the start-up
script is not really essential].
It seems that 'ISA' support has been dropped altogether, but even if
it was an ugly hack, it was still better than having no sensor support
at all!

(In reply to comment #4)
> (In reply to comment #3)
> The version reported above actually is the one you are referring to.
> Btw, how can you claim that 'i2c-isa' does not exist anymore? It is
> still present in the modules directory of the latest update kernel.

It is deprecated, all drivers are being moved away from it once that is done it
will be removed.

> In the past it was sufficient to modprobe 'lm78.ko', 'i2c-isa.ko',
> and 'sensors.ko' to obtain a working command 'sensors' [the start-up
> script is not really essential].
> It seems that 'ISA' support has been dropped altogether, but even if
> it was an ugly hack, it was still better than having no sensor support
> at all!

I fully agree, the migration to a regular isa driver, should in no way impact
the functionality, let alone make things stop working. You say you did use the
lm78 driver in the past without any issues, correct?

Can you please do the following as root:
rmmod lm78
modprobe lm78
sensors > sensors.log
sensors -u > sensorsu.log
dmesg > dmesg.log
ls -l /sys/class/hwmon/hwmon?/device/ > ls.log

And then attach the resulting log files (in a tar or one by one) ? Thanks.

No need to attach whatsoever, .. the output of the various commands
is essentially nil:

sensors:
 No sensors found!
 Make sure you loaded all the kernel drivers you need.
 Try sensors-detect to find out which these are.

sensors -u:
 No sensors found!
 Make sure you loaded all the kernel drivers you need.
 Try sensors-detect to find out which these are.

dmesg:
 [no additional entries]

/sys/class/hwmon:
 [empty]

I will try with various live CDs of different age to check wether and
until when hardware monitoring worked. If I remember correctly, 'FC6'
was o.k. in this respect, but I have to check. I had never encountered
any issue ever since I got 'lm_sensors' to work in summer 2001.

Created attachment 159884 [details]
modified test version of lm78 driver

Okay, since /sys/class/hwmon is empty this definetely is a kernel issue and not
a lm_sensors issue, so I'm changing the component (for bookkeeping reasons
only).

This is most likely caused by this patch:
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-March/019227.html

Which not only converts the driver to a platform driver, but at the same time
also makes the detection code more strict (which reallyu should have been a
seperate patch).

I've attached a modified standalone version of the lm78 driver with many
debugging printf's added to help debug this, to use:
sudo yum -y install kernel-devel
<untar>
cd lm78
make
rmmod lm78
insmod lm78.ko
dmesg

This should help us pinpoint the problem, I've also added a param to skip the
detection, to see if the problem is really there, to try this do
<in lm78 dir>
rmmod lm78
insmod lm78.ko force_isa_detect=1
sensors

Many thanks for your time and testing!

Excellent! After simply loading the modified 'lm78.ko', one obtains:

  lm78: unknown chip type: 20 ,

but 'sensors' still fails. However, after adding 'force_isa_detect=1',
'dmesg' still reports 'lm78: unknown chip type: 20' **but** 'sensors'
now reports compelling values for the hardware observables:

 'lm78-isa-0290
  Adapter: ISA adapter
  VCore 1:   +2.51 V  (min =  +3.47 V, max =  +2.48 V)   ALARM
  VCore 2:   +2.54 V  (min =  +3.02 V, max =  +1.50 V)   ALARM
  +3.3V:     +3.38 V  (min =  +0.40 V, max =  +3.86 V)   
  +5V:       +5.08 V  (min =  +2.04 V, max =  +0.22 V)   ALARM
  +12V:     +12.10 V  (min =  +6.44 V, max =  +4.92 V)   ALARM
  -12V:     -11.79 V  (min = -13.18 V, max = -13.85 V)   ALARM
  -5V:       -5.10 V  (min =  -4.21 V, max =  -4.96 V)   ALARM
  fan1:     3708 RPM  (min = 5152 RPM, div = 2)          ALARM
  fan2:     3609 RPM  (min = 3276 RPM, div = 2)          
  fan3:        0 RPM  (min = 10546 RPM, div = 2)          ALARM
  temp:      +35.0°C  (high =   -37°C, hyst =   -48°C)   
  vid:       +2.50 V
  alarms:   Chassis intrusion detection                  ALARM' .

Version-Release number of selected component (if applicable):
kernel-2.6.22.1-27.fc7

(In reply to comment #8)
> Excellent! After simply loading the modified 'lm78.ko', one obtains:
> 
>   lm78: unknown chip type: 20 ,
> 
> but 'sensors' still fails. However, after adding 'force_isa_detect=1',
> 'dmesg' still reports 'lm78: unknown chip type: 20' **but** 'sensors'
> now reports compelling values for the hardware observables:
> 
>  'lm78-isa-0290
>   Adapter: ISA adapter
>   VCore 1:   +2.51 V  (min =  +3.47 V, max =  +2.48 V)   ALARM
>   VCore 2:   +2.54 V  (min =  +3.02 V, max =  +1.50 V)   ALARM
>   +3.3V:     +3.38 V  (min =  +0.40 V, max =  +3.86 V)   
>   +5V:       +5.08 V  (min =  +2.04 V, max =  +0.22 V)   ALARM
>   +12V:     +12.10 V  (min =  +6.44 V, max =  +4.92 V)   ALARM
>   -12V:     -11.79 V  (min = -13.18 V, max = -13.85 V)   ALARM
>   -5V:       -5.10 V  (min =  -4.21 V, max =  -4.96 V)   ALARM
>   fan1:     3708 RPM  (min = 5152 RPM, div = 2)          ALARM
>   fan2:     3609 RPM  (min = 3276 RPM, div = 2)          
>   fan3:        0 RPM  (min = 10546 RPM, div = 2)          ALARM
>   temp:      +35.0°C  (high =   -37°C, hyst =   -48°C)   
>   vid:       +2.50 V
>   alarms:   Chassis intrusion detection                  ALARM' .

Do these match the readings you used to get with FC-6?

(In reply to comment #8)
> Excellent! After simply loading the modified 'lm78.ko', one obtains:
> 
>   lm78: unknown chip type: 20 ,
> 

Ah, further digging has solved the mistery 20 is a valid chip ID. The isa detect
code should accept the 20 as chip type, but this was accidentally omitted. I'll
send a patch for upstream inclusion asap. This will likely hopefully make 2.6.23

I don't think Dave Jones will be willing to carry a patch for this in the Fedora
kernel rpms, so you will have to use the version attached here with the force
parameter for now, the fix will eventually find its way into the Fedora kernels
through upstream. I'll attach the patch really fixing this for those interested.

So I'm closing this as upstream. If you think Dave should make the time to
include this, please reopen and reassign to davej , but he really
doesn't have time for small things like this, so your chances are very minimal.

(In reply to comment #10)
> Do these match the readings you used to get with FC-6?

The 'ALARM' messages on the right are not meaningful, as I haven't
adjusted 'sensors.conf' to fit the specifications of my mainboard.
The two left columns are what one has to look at, and for those,
expected voltages [#1] fit measured voltages [#2] very well. The
'RPM' values are correct, too.

Created attachment 159889 [details]
Patch fixing this as send upstream for merging

Thanks Hans for fixing my mistake.