Bug 508192 - sensors correctly functioning in F10 are not loadable in F11
Summary: sensors correctly functioning in F10 are not loadable in F11
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: lm_sensors
Version: 11
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-25 23:56 UTC by John Mellor
Modified: 2015-03-05 01:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-02 08:22:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description John Mellor 2009-06-25 23:56:21 UTC
Description of problem:
Sensors-detect worked correctly in F10, now does not.  Sensors are detected but cannot be loaded.


Version-Release number of selected component (if applicable):
lm_sensors-3.1.0-1.fc11.i586


How reproducible:
Every time


Steps to Reproduce:
1. run sensors-detect

  
Actual results:
sensor modules cannot be loaded as detected


Expected results:
Same as in F10, sensors now working


Additional info:
# sensors-detect 
# sensors-detect revision 5666 (2009-02-26 17:15:04 +0100)
# Board: http://www.abit.com.tw/ NF7-S/NF7,NF7-V (nVidia-nForce2)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): 
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD K10 thermal sensors...                                  No
Intel Core family thermal sensor...                         No
Intel AMB FB-DIMM thermal sensor...                         No
VIA C7 thermal and voltage sensors...                       No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): 
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Fintek'...                       Yes
Found `Winbond W83627HF/F/HG/G Super IO Sensors'            Success!
    (address 0x290, driver `w83627hf')
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Fintek'...                       No
Trying family `ITE'...                                      No

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We have to read from arbitrary I/O ports to probe for such interfaces.
This is normally safe. Do you want to scan for IPMI interfaces?
(YES/no): 
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (yes/NO): yes
Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM79' at 0x290...       No
Probing for `Winbond W83781D' at 0x290...                   No
Probing for `Winbond W83782D' at 0x290...                   No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): 
Using driver `i2c-nforce2' for device 0000:00:01.1: nVidia Corporation nForce2 SMBus (MCP)
Module i2c-dev loaded successfully.

Next adapter: SMBus nForce2 adapter at 5000 (i2c-0)
Do you want to scan it? (yes/NO/selectively): yes
Client found at address 0x4e
Probing for `National Semiconductor LM75'...                No
Probing for `Dallas Semiconductor DS75'...                  No
Probing for `Dallas Semiconductor DS1621/DS1631'...         No
Probing for `Analog Devices ADM1021'...                     No
Probing for `Analog Devices ADM1021A/ADM1023'...            No
Probing for `Maxim MAX1617'...                              No
Probing for `Maxim MAX1617A'...                             No
Probing for `Maxim MAX1668'...                              No
Probing for `Maxim MAX1805'...                              No
Probing for `Maxim MAX1989'...                              No
Probing for `Maxim MAX6655/MAX6656'...                      No
Probing for `TI THMC10'...                                  No
Probing for `National Semiconductor LM84'...                No
Probing for `Genesys Logic GL523SM'...                      No
Probing for `Onsemi MC1066'...                              No
Probing for `Maxim MAX1618'...                              No
Probing for `Maxim MAX1619'...                              No
Probing for `National Semiconductor LM82/LM83'...           No
Probing for `Maxim MAX6654/MAX6690'...                      No
Probing for `Maxim MAX6659'...                              No
Probing for `Maxim MAX6647'...                              No
Probing for `Maxim MAX6680/MAX6681'...                      No
Probing for `Texas Instruments TMP411'...                   No
Probing for `National Semiconductor LM64'...                No
Probing for `Maxim MAX6633/MAX6634/MAX6635'...              No
Probing for `Fintek F75121R/F75122R/RG (VID+GPIO)'...       No
Probing for `Fintek F75111R/RG/N (GPIO)'...                 No
Probing for `ITE IT8201R/IT8203R/IT8206R/IT8266R'...        No
Client found at address 0x50
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 Yes
    (confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'...                                No
Client found at address 0x51
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 Yes
    (confidence 8, not a hardware monitoring chip)
Client found at address 0x52
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 Yes
    (confidence 8, not a hardware monitoring chip)

Next adapter: SMBus nForce2 adapter at 5100 (i2c-1)
Do you want to scan it? (yes/NO/selectively): yes

Now follows a summary of the probes I have just done.
Just press ENTER to continue: 

Driver `w83627hf':
  * ISA bus, address 0x290
    Chip `Winbond W83627HF/F/HG/G Super IO Sensors' (confidence: 9)

Do you want to overwrite /etc/sysconfig/lm_sensors? (YES/no): 
Starting lm_sensors: loading module w83627hf No sensors found!
Make sure you loaded all the kernel drivers you need.
Try sensors-detect to find out which these are.
                                                           [FAILED]
Unloading i2c-dev... OK

Comment 1 Tommi R. 2009-07-02 07:29:42 UTC
I cannot solve the problem but as additional information I have exactly the same problem with Abit KW7 board (uses same w83627hf module). It worked fine with F10 but not anymore with F11.

If I manually try to load the module I got error:

bash-4.0# modprobe w83627hf
FATAL: Error inserting w83627hf (/lib/modules/2.6.29.5-191.fc11.i586/kernel/drivers/hwmon/w83627hf.ko): Device or resource busy
bash-4.0#

Please advice how to debug this more, why this is busy?

BR
Tommi

Comment 2 Hans de Goede 2009-07-02 08:22:29 UTC
Hi,

This become a bit of a FAQ, so I've made a blog post about this explaining what is going on (and why this is not a bug), this blog post also includes a workaround:

http://hansdegoede.livejournal.com/7932.html

Regards,

Hans

Comment 3 John Mellor 2009-07-02 23:56:46 UTC
I very strongly disagree.  It certainly IS a bug, and it is not appropriate to close this issue without a fix.

If the kernel is now pre-empting the use of the old mechanism, then the package should be invoking the appropriate API from the kernel to do these probes instead of doing them itself.  This means that the package should be redesigned to do this, and not left in a non-working state.

As it sits, the package is not usable, the workaround is just-plain weird, and we're left with no sensor monitors of any kind.  This is a major decrease in functionality that is highly visible.

Comment 4 John Mellor 2009-07-03 00:02:28 UTC
This workaround urgently needs to be placed in the Fedora 11 FAQ, as just about every user will want to implement it on every install.

Comment 5 Hans de Goede 2009-07-03 06:02:39 UTC
Hi,

(In reply to comment #3)
> I very strongly disagree.  It certainly IS a bug, and it is not appropriate to
> close this issue without a fix.
> 

I'm sorry you don't like this, but the *old* behaviour is the buggy one, not
the new behaviour. For example an asus eeepc laptops we were wrecking
i2c transactions as both we and the BIOS was talking to the smbus controller
at the same time.

This is dangerous stuff, all it takes is one wrong i2c write to mess up the
little eeproms on your ram modules which make the computer recognize the RAM's,
after which your computer will no longer work and you can basically throw your RAM's away.

> If the kernel is now pre-empting the use of the old mechanism, then the package
> should be invoking the appropriate API from the kernel to do these probes
> instead of doing them itself.  This means that the package should be redesigned
> to do this, and not left in a non-working state.

There is nothing wrong with the package, not with the kernel, we are very
*deliberately* disallowing the loading of modules which conflict with the ACPI
code, if anything it is a BIOS bug, go complain to your motherboard vendor.

For example Asus has this problem solved by offering an ACPI interface to get
the sensors reading through ACPI (as ACPI owns the hwmon chip). This means
that not only this problem does not exist with Asus boards, but hardware
monitoring on them is 100% plug and play, no need to run sensors-detect, no
need to tweak sensors.conf, it just works.

Abit OTOH has always been notoriously bad in supporting Linux, for example their
own custom Abit uGuru chips for hardware monitoring had to be reverse engineered. Trust me on this, I'm the person who wrote the Linux Abit uGuru drivers, and they aren't pretty.

Regards,

Hans


Note You need to log in before you can comment on or make changes to this bug.