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
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
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
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.
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.
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