Dear Jean,
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
Thanks for that.
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.
OK, I had not realised there was yet another aspect to the enumeration
beyond the module load order :(
"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.
I will look in to that option, though a quick look at the man page shows
there is very little documentation on what you actually do with each
function.
subsystem) have tried it but it simply doesn't work. For most subsystems
this is now handles by udev, unfortunately hwmon devices have no node
in /dev so udev is of no use in our case.
In the past the watchdog used /dev/temperature for a single reading
(though in unspecified units) and I had assumed the /sys/class/hwmon
devices could be used in a similar manner. It would be much nicer if
there was a /dev entry that had stable names for the underlying hardware.
The code there is horrible ;)
Indeed, but it seems to work!
/etc/modules is a Debian/Ubuntu specific approach. Your workaround
should work fine as far as I can see, although this is obviously a step
backwards (driver autoloading is a great feature.) Unfortunately we
autoloading is great until it shows up something unstable in the system
behaviour!
Note though that I do not have the problem you describe with openSUSE.
Maybe I am just very lucky, or maybe Debian/Ubuntu starts more services
in parallel. If they would wait for driver autoloading to be finished
before starting the lm_sensors and then fancontrol services, that would
probably solve your problem.
Ubuntu has gone to using the upstart system for start-up and one of its
selling features is the greater options for paralleled starting.
Unfortunately the last couple of years have shown lots of problems with
part-migrated packages that are not started properly due to dependencies
that have not been properly covered.
I think though the problem here is the autoload takes place along side
the manual load of /etc/modules and due to the enumeration issue who (of
the hardware modules) gets there first changes the system behaviour.
Regards, Paul
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
