Hi Paul, On Sat, 01 Jun 2013 11:27:25 +0100, Paul Crawford wrote: > I encountered a problem using the lm-sensors package along with the > fancontrol package where the various drivers for the temperature sensing > chips would be loaded in differing orders at boot time. Yes, this can happen, depending on the hardware. > This leads to the abstracted paths of, for example, > '/sys/class/hwmon/hwmon0' and '/sys/class/hwmon/hwmon1' changing places > and the fancontrol package doing nothing as it believes the hardware is > different or misconfigured. The latest version of fancontrol supports absolute device paths, which should help a bit in this respect. It isn't perfect yet, because: 1* pwmconfig still writes relative paths so you have to edit /etc/fancontrol manually. I have just created a ticket for that: http://www.lm-sensors.org/ticket/2388 2* Absolute paths aren't necessarily persistent. PCI and platform device paths are persistent but I2C bus numbers are not. So using absolute paths doesn't guarantee that fancontrol will find the devices it looks for after every reboot. > This is also a risk for the Linux watchdog daemon that could be using > such a path for temperature sensing (I added the capability recently to > use lm-sensors outputs), leading to a far more irksome problem than > simply full-speed fans! "lm-sensors outputs"? If you need to access hardware monitoring information, please use libsensors. The problems you mentioned with fancontrol precisely come from the fact that it does not use libsensors. libsensors gives hardware monitoring devices stable names. (See http://www.lm-sensors.org/ticket/2238 for one remaining issue though.) > Is this enumeration something that lm-sensors performs, or is it a > kernel issue? As this appears to be quite important for actually using > the capabilities, what can be done to fix it? "lm-sensors" is a package name, it does not perform anything. The relevant components are, in order: the hardware monitoring driver, the kernel core, the sysfs interface, libsensors and ultimately "sensors" or whatever application you're using. The kernel makes no guarantee about device name stability. Some subsystems (most notably the sound subsystem) have tried it but it simply doesn't work. For most subsystem this is now handles by udev, unfortunately hwmon devices have no node in /dev so udev is of no use in our case. > > I added my crude solution (to make sure all of the modules are in > /etc/modules, and not some auto-loaded and others explicitly added) to > the bug report here: > > https://bugs.launchpad.net/ubuntu/+source/lm-sensors-3/+bug/576602 > > Regards, Paul -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
