[lm-sensors] Problem with order of module loading

[lm-sensors] Problem with order of module loading

[Volker Kuhlmann]

There is a problem with kernels using the /sys/class/hwmon interface and
the order in which modules are loaded. For lm_sensors directly this may
not matter, but it will cause all/most/some fancontrol scripts to fail.

My Gigabyte GA-K8NF-9 mobo needs 

> cat /etc/sysconfig/lm_sensors
MODULE_0=it87
MODULE_1=k8temp

When I run /etc/init.d/lm_sensors restart from the command line it
always works:

 /sys/class/hwmon/hwmon0 -> ../../devices/platform/it87.656/hwmon/hwmon0
 /sys/class/hwmon/hwmon1 -> ../../devices/pci0000:00/0000:00:18.3/hwmon/hwmon1

However when booting, the fancontrol part of the service
always fails. The reason is that when booting, hwmon entries are always
created in reverse order.

My workaround for now is

> cat /etc/modprobe.d/sensors-hwmon-order
install k8temp /sbin/modprobe it87; /sbin/modprobe --ignore-install k8temp
remove k8temp /sbin/modprobe --ignore-remove --remove k8temp && /sbin/modprobe --remove it87

This hasn't been a problem for previous kernels. Was this by chance, or
has something changed?

Volker

-- 
Volker Kuhlmann			is list0570 with the domain in header
http://volker.dnsalias.net/	Please do not CC list postings to me.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Problem with order of module loading

[Jean Delvare]

Hi Volker,

On Sun, 25 Jan 2009 15:11:51 +1300, Volker Kuhlmann wrote:
> There is a problem with kernels using the /sys/class/hwmon interface and
> the order in which modules are loaded. For lm_sensors directly this may
> not matter, but it will cause all/most/some fancontrol scripts to fail.
> 
> My Gigabyte GA-K8NF-9 mobo needs 
> 
> > cat /etc/sysconfig/lm_sensors
> MODULE_0=it87
> MODULE_1=k8temp
> 
> When I run /etc/init.d/lm_sensors restart from the command line it
> always works:
> 
>  /sys/class/hwmon/hwmon0 -> ../../devices/platform/it87.656/hwmon/hwmon0
>  /sys/class/hwmon/hwmon1 -> ../../devices/pci0000:00/0000:00:18.3/hwmon/hwmon1
> 
> However when booting, the fancontrol part of the service
> always fails. The reason is that when booting, hwmon entries are always
> created in reverse order.

No, that's not the reason. The reason is that the k8temp driver is one
of the few hwmon drivers which is loaded automatically at boot time
(because the K8 thermal sensors are implemented as a PCI device).

> My workaround for now is
> 
> > cat /etc/modprobe.d/sensors-hwmon-order
> install k8temp /sbin/modprobe it87; /sbin/modprobe --ignore-install k8temp
> remove k8temp /sbin/modprobe --ignore-remove --remove k8temp && /sbin/modprobe --remove it87
> 
> This hasn't been a problem for previous kernels. Was this by chance, or
> has something changed?

Can't really say as you didn't tell what was version your previous
kernel was and what version your new kernel is. But basically this
problem became frequent since the k8temp driver exists and auto-loads.
There have been other PCI hwmon devices in the past (drivers via686a,
vt8231) but they where usually the only hwmon device on the board so
the loading order didn't matter.

More specifically, the problem is that "service lm_sensors start" (or
whatever the command is for your specific distribution) at boot time is
influenced by the driver auto-loading, while "service lm_sensors
restart" isn't (because it removes all the drivers first.)

I'm not too sure how we can fix this problem. One possibility would be
to not list in /etc/sysconfig/lm_sensors the drivers which were already
loaded before sensors-detect is run. However this could be a problem if
sensors-detect is ran again a second time, because all required hwmon
drivers would be already loaded so none would be listed
in /etc/sysconfig/lm_sensors. This problem can be avoided by stopping
the lm_sensors service before running sensors-detect. I think some
distributions do that already.

I've created ticket 2368 to track this issue:
http://www.lm-sensors.org/ticket/2368

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Problem with order of module loading

[Volker Kuhlmann]

Hi Jean,

Thanks for your answer.

On Sun 25 Jan 2009 23:00:03 NZDT +1300, Jean Delvare wrote:

> > However when booting, the fancontrol part of the service
> > always fails. The reason is that when booting, hwmon entries are always
> > created in reverse order.
> 
> No, that's not the reason. The reason is that the k8temp driver is one
> of the few hwmon drivers which is loaded automatically at boot time
> (because the K8 thermal sensors are implemented as a PCI device).

Ok. Bottom line is still the load order is different, so the entries in
/sys/class/hwmon/ have a different order.

> Can't really say as you didn't tell what was version your previous
> kernel was and what version your new kernel is.

Current 2.6.27.7-9-default #1 SMP 2008-12-04, openSUSE 11.1.
Previous: pick pretty much any version of SUSE.
The immediately previous kernel was 2.6.22.5. It's config was also
MODULE_0=it87
MODULE_1=k8temp
but I never noticed the problem in a year of using it.

> More specifically, the problem is that "service lm_sensors start" (or
> whatever the command is for your specific distribution) at boot time is
> influenced by the driver auto-loading, while "service lm_sensors
> restart" isn't (because it removes all the drivers first.)

One could try in "start" to unload the modules first, which was one
option I considered. But one of the modules may not unload, and it may
also violate init script requirements.

> I'm not too sure how we can fix this problem. One possibility would be
> to not list in /etc/sysconfig/lm_sensors the drivers which were already
> loaded before sensors-detect is run. However this could be a problem if
> sensors-detect is ran again a second time, because all required hwmon
> drivers would be already loaded so none would be listed
> in /etc/sysconfig/lm_sensors.

I think it may be dangerous to not list prerequisites.

> This problem can be avoided by stopping
> the lm_sensors service before running sensors-detect. I think some
> distributions do that already.

I'm pretty sure I ran sensors-detect while the service was not yet
enabled - no point starting a service of which I knew it was
unconfigured, and which will not run without manual configuration (that
being /etc/sensors.conf).

It wouldn't really solve the problem anyway. If you stop the service at
the start of sensors-detect, you still have the same discrepency between
some modules being loaded at boot time, and service restart. It looks to
me like the only reliable way to control the order of module loading is
to unload them all first.

But sensors isn't really affected, only fancontrol. Maybe identifying
controllers by hwmon0, hwmon1 is inadequate, and fancontrol needs to be
more intelligent and to automatically find its controllers?

> http://www.lm-sensors.org/ticket/2368

Thanks.

Volker

-- 
Volker Kuhlmann			is list0570 with the domain in header
http://volker.dnsalias.net/	Please do not CC list postings to me.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Problem with order of module loading

[Jean Delvare]

On Mon, 26 Jan 2009 00:08:45 +1300, Volker Kuhlmann wrote:
> On Sun 25 Jan 2009 23:00:03 NZDT +1300, Jean Delvare wrote:
> > Can't really say as you didn't tell what was version your previous
> > kernel was and what version your new kernel is.
> 
> Current 2.6.27.7-9-default #1 SMP 2008-12-04, openSUSE 11.1.
> Previous: pick pretty much any version of SUSE.
> The immediately previous kernel was 2.6.22.5. It's config was also
> MODULE_0=it87
> MODULE_1=k8temp
> but I never noticed the problem in a year of using it.

Could be that the lm_sensors init script has been slightly adjusted
between openSUSE 10.3 and 11.1, I don't really remember.

> > More specifically, the problem is that "service lm_sensors start" (or
> > whatever the command is for your specific distribution) at boot time is
> > influenced by the driver auto-loading, while "service lm_sensors
> > restart" isn't (because it removes all the drivers first.)
> 
> One could try in "start" to unload the modules first, which was one
> option I considered. But one of the modules may not unload, and it may
> also violate init script requirements.

Interesting idea. That should indeed work in the general case, even
though there may be rare cases where unloading might not work (module
unloading might be disabled in the kernel, and a module may be in use.)

I don't see any init script requirement that we would violate. What
matters is that we get things to work with no drawbacks, the
implementation details are really up to us.

> > I'm not too sure how we can fix this problem. One possibility would be
> > to not list in /etc/sysconfig/lm_sensors the drivers which were already
> > loaded before sensors-detect is run. However this could be a problem if
> > sensors-detect is ran again a second time, because all required hwmon
> > drivers would be already loaded so none would be listed
> > in /etc/sysconfig/lm_sensors.
> 
> I think it may be dangerous to not list prerequisites.

I'm not sure what you name a prerequisite here? hwmon modules?

The fact that the lm_sensors service must load the hwmon modules is a
simple consequence of the fact that these drivers did historically not
auto-load. If we know that some modules auto-load, then there is no
need to list them.

> > This problem can be avoided by stopping
> > the lm_sensors service before running sensors-detect. I think some
> > distributions do that already.
> 
> I'm pretty sure I ran sensors-detect while the service was not yet
> enabled - no point starting a service of which I knew it was
> unconfigured, and which will not run without manual configuration (that
> being /etc/sensors.conf).
> 
> It wouldn't really solve the problem anyway. If you stop the service at
> the start of sensors-detect, you still have the same discrepency between
> some modules being loaded at boot time, and service restart. It looks to
> me like the only reliable way to control the order of module loading is
> to unload them all first.

I'm not sure why you think my approach wouldn't work. Let's take the
case of your board: the k8temp driver loads automatically, the it87
driver doesn't.

At first run, sensors-detect would stop the lm_sensors service (no
effect as the service wasn't configured yet.) It would detect k8temp and
it87, but seeing that k8temp is already loaded, would only list it87
in /etc/sysconfig/lm_sensors.

At this point, starting the lm_sensors service only loads it87, because
k8temp is already loaded. Likewise, stopping or restarting the
lm_sensors service only unloads the it87 driver.

This means that a further run of sensors-detect will only unload the
it87 driver. Then it will see that k8temp is loaded and again will not
list it in /etc/sysconfig/lm_sensors.

Basically the idea is to leave auto-loaded drivers alone and only care
about drivers which need to be loaded explicitly. For what it's worth,
this is exactly what sensors-detect already does (in SVN, that's a
recent change) for i2c bus drivers. So doing the same for hwmon drivers
themselves would be along the same line.

The only cases which I see won't work properly are:
* Upgrade from a system where k8temp or similar modules are already
  listed in /etc/sysconfig/lm_sensors. Could be handled at
  distribution level with a post-install script.
* Driver being autoloaded at some point while it was not beforehand.
  A relatively rare case, but not unseen.

Are you worried by these drawbacks, or are there other problems which I
did not see?

Your approach doesn't have these drawbacks, admittedly, but it has a
minor performance issue. I also see potential problems for drivers with
more than one function, as the forced module reloading might have side
effects.

> But sensors isn't really affected, only fancontrol. Maybe identifying
> controllers by hwmon0, hwmon1 is inadequate, and fancontrol needs to be
> more intelligent and to automatically find its controllers?

We clearly have a general issue at the kernel interface level due to
the lack of persistent device names. The usual solution (udev) doesn't
work for us because hwmon devices have no device nodes in /dev, only a
sysfs interface.

Going with the device paths (e.g. /sys/devices/platform/it87.656) works
well for platform devices, but it doesn't work that well for
SMBus-based chips, for the same reason hwmon class devices don't work:
i2c bus numbers aren't persistent. libsensors has a custom device
naming scheme which predates kernel 2.6 and udev, and solves all these
issues, unfortunately in user-space rather than at the kernel interface
level as udev does.

Getting fancontrol to do the same as sensors means either duplicating
the libsensors device naming logic there, or changing fancontrol to use
libsensors (meaning that you have to rewrite it in a different language
first, as a shell script can't use a C library.) Or maybe an
intermediate solution would be a binary helper converting hwmon class
names to libsensors names and back. After all, I already added an
option to "sensors" to list the i2c buses which have at least one hwmon
device on them. We could have more options to address the hwmon device
naming issue.

As a side note, fancontrol started as a quick hack to get the fan
control job done. But it is showing its limits every now and then. We
have maintained it so far, but clearly writing something more robust,
flexible and user-friendly would be very needed (if such a replacement
doesn't exist yet...)

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Problem with order of module loading

[Volker Kuhlmann]

On Mon 26 Jan 2009 02:47:24 NZDT +1300, Jean Delvare wrote:

> Could be that the lm_sensors init script has been slightly adjusted
> between openSUSE 10.3 and 11.1, I don't really remember.

This is the diff:

-# If sensors isn't supported by the kernel, try loading the module...
-[ -e /sys/bus/i2c/devices ] || /sbin/modprobe i2c-dev &>/dev/null
-
-# Don't bother if /proc/sensors still doesn't exist, kernel doesn't have
-# support for sensors.
-[ -e /sys/bus/i2c/devices ] || exit 0
-
-# If sensors was not already running, unload the module...
-[ -e /var/lock/subsys/sensors ] || /sbin/modprobe -r i2c-dev &>/dev/null

The problem started with /sys/class, but /sys/bus worked?

> I don't see any init script requirement that we would violate. What
> matters is that we get things to work with no drawbacks, the
> implementation details are really up to us.

> I'm not sure what you name a prerequisite here? hwmon modules?

Yes. With or without fancontrol, the modules need to be loaded for the
service, therefore are a prerequsite, AFAIU.

> I'm not sure why you think my approach wouldn't work. Let's take the
> case of your board: the k8temp driver loads automatically, the it87
> driver doesn't.
> 
> At first run, sensors-detect would stop the lm_sensors service (no
> effect as the service wasn't configured yet.) It would detect k8temp and
> it87, but seeing that k8temp is already loaded, would only list it87
> in /etc/sysconfig/lm_sensors.
> 
> At this point, starting the lm_sensors service only loads it87, because
> k8temp is already loaded. Likewise, stopping or restarting the
> lm_sensors service only unloads the it87 driver.
> 
> This means that a further run of sensors-detect will only unload the
> it87 driver. Then it will see that k8temp is loaded and again will not
> list it in /etc/sysconfig/lm_sensors.

Ah yes, put it like that, it should work. It would be very sensitive to
run-status being the same as boot-status though. Is this robust enough?

> The only cases which I see won't work properly are:
> * Upgrade from a system where k8temp or similar modules are already
>   listed in /etc/sysconfig/lm_sensors. Could be handled at
>   distribution level with a post-install script.

I wouldn't put money on all distributors with a new release of lm_sensors
picking up on the new requirement to deal with post-install scripts...

> * Driver being autoloaded at some point while it was not beforehand.
>   A relatively rare case, but not unseen.

This is what I meant - rare, but no guarantee.

> Your approach doesn't have these drawbacks, admittedly, but it has a
> minor performance issue.

# /usr/bin/time rclm_sensors restart
Shutting down sensors, stopping fan control:                                             done
Starting up sensors, starting fan control:                                               done
0.06user 0.08system 0:00.53elapsed 27%CPU (0avgtext+0avgdata 0maxresident)k
456inputs+0outputs (3major+6562minor)pagefaults 0swaps

With unloading all modules first:

# /usr/bin/time /tmp/root/lm_sensors restart
Shutting down sensors, stopping fan control:                                             done
Starting up sensors, starting fan control:                                               done
0.07user 0.12system 0:00.55elapsed 35%CPU (0avgtext+0avgdata 0maxresident)k
24inputs+32outputs (0major+8664minor)pagefaults 0swaps

20 milliseconds longer, AMD64 3200+ CPU, system ca 3y old, not top-top
then.

I don't think I'd worry about it.

> I also see potential problems for drivers with
> more than one function, as the forced module reloading might have side
> effects.

That's what I am worried about, plus the module being in use and therefore
not unloadable (incl its depedencies).

I don't see an allround good solution.

> We clearly have a general issue at the kernel interface level due to
> the lack of persistent device names.

That's what I feared, hence bringing it up.

> Going with the device paths (e.g. /sys/devices/platform/it87.656) works
> well for platform devices, but it doesn't work that well for
> SMBus-based chips, for the same reason hwmon class devices don't work:
> i2c bus numbers aren't persistent. libsensors has a custom device
> naming scheme which predates kernel 2.6 and udev, and solves all these
> issues, unfortunately in user-space rather than at the kernel interface
> level as udev does.
> 
> Getting fancontrol to do the same as sensors means either duplicating
> the libsensors device naming logic there, or changing fancontrol to use
> libsensors (meaning that you have to rewrite it in a different language
> first, as a shell script can't use a C library.)

A wrapper for the library, which outputs device names to /sys/class/...
pairs one per line in a format easily parsable by a shell script?

> Or maybe an
> intermediate solution would be a binary helper converting hwmon class
> names to libsensors names and back.

Only the sensors names to filesystem names would really be needed.

> As a side note, fancontrol started as a quick hack to get the fan
> control job done. But it is showing its limits every now and then.

:)

I had to mess with it because for my mobo it was plain not working at
all (useful PWM values 4..12, not 30..255).

What I'd really like to write is a panel applet which does all of this:

* Monitor all hardware, this includes sensors as well as hard disks
(smartmontools!).

* Control hardware as needed, e.g. fans, perhaps CPU performance.
Applets for the CPU already exist.

* Warn if hardware goes pear-shaped, e.g. fans below min speed, disks
failing or getting too hot, ..., by producing suitable popups,
repeatedly as configured or clicked away by the user.

* With each warning, give information to users who don't have any
hardware understanding, saying how serious the problem is nd what can be
done about it.

* With mobo sensors I don't see the day where vendors will give decent
info in a generic usable form. It's not happening with hard disks
either, some smart info is plain shocking, also smart standards seem to
be vague in places. The only workaround to that I can see is to have a
component database, and have the application pull updates automatically
say once a week.

* There would need to be some GUI app to configure the lot first. Could
be integrated with the applet of course. Similar in style to the superb
kinternet from SUSE.

I like this in particular because neither Billyware nor Macsware have
anything similar, and Linux could claim a user-friendly first.

Volker

-- 
Volker Kuhlmann			is list0570 with the domain in header
http://volker.dnsalias.net/	Please do not CC list postings to me.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Problem with order of module loading

[Jean Delvare]

Hi Volker,

On Mon, 26 Jan 2009 22:47:36 +1300, Volker Kuhlmann wrote:
> On Mon 26 Jan 2009 02:47:24 NZDT +1300, Jean Delvare wrote:
> > Could be that the lm_sensors init script has been slightly adjusted
> > between openSUSE 10.3 and 11.1, I don't really remember.
> 
> This is the diff:
> 
> -# If sensors isn't supported by the kernel, try loading the module...
> -[ -e /sys/bus/i2c/devices ] || /sbin/modprobe i2c-dev &>/dev/null
> -
> -# Don't bother if /proc/sensors still doesn't exist, kernel doesn't have
> -# support for sensors.
> -[ -e /sys/bus/i2c/devices ] || exit 0
> -
> -# If sensors was not already running, unload the module...
> -[ -e /var/lock/subsys/sensors ] || /sbin/modprobe -r i2c-dev &>/dev/null
> 
> The problem started with /sys/class, but /sys/bus worked?

I don't think these changes have anything to do with your problem.
lm_sensors has never needed i2c-dev so the above was dead code to start
with.

> > I'm not sure why you think my approach wouldn't work. Let's take the
> > case of your board: the k8temp driver loads automatically, the it87
> > driver doesn't.
> > 
> > At first run, sensors-detect would stop the lm_sensors service (no
> > effect as the service wasn't configured yet.) It would detect k8temp and
> > it87, but seeing that k8temp is already loaded, would only list it87
> > in /etc/sysconfig/lm_sensors.
> > 
> > At this point, starting the lm_sensors service only loads it87, because
> > k8temp is already loaded. Likewise, stopping or restarting the
> > lm_sensors service only unloads the it87 driver.
> > 
> > This means that a further run of sensors-detect will only unload the
> > it87 driver. Then it will see that k8temp is loaded and again will not
> > list it in /etc/sysconfig/lm_sensors.
> 
> Ah yes, put it like that, it should work. It would be very sensitive to
> run-status being the same as boot-status though. Is this robust enough?

I agree it is a little fragile. It should work in the general case if
the user doesn't edit the configuration file manually and doesn't load
or unload hwmon drivers on its own. My hope is that users who start
loading or unloading drivers or editing configuration files will know
how to fix things if they break. But maybe that's too optimistic.

> > The only cases which I see won't work properly are:
> > * Upgrade from a system where k8temp or similar modules are already
> >   listed in /etc/sysconfig/lm_sensors. Could be handled at
> >   distribution level with a post-install script.
> 
> I wouldn't put money on all distributors with a new release of lm_sensors
> picking up on the new requirement to deal with post-install scripts...

I am doing my best to let packagers know when they should pay attention
to that kind of things. So far it went well.

> > (...)
> > Your approach doesn't have these drawbacks, admittedly, but it has a
> > minor performance issue.
> 
> # /usr/bin/time rclm_sensors restart
> Shutting down sensors, stopping fan control:                                             done
> Starting up sensors, starting fan control:                                               done
> 0.06user 0.08system 0:00.53elapsed 27%CPU (0avgtext+0avgdata 0maxresident)k
> 456inputs+0outputs (3major+6562minor)pagefaults 0swaps
> 
> With unloading all modules first:
> 
> # /usr/bin/time /tmp/root/lm_sensors restart
> Shutting down sensors, stopping fan control:                                             done
> Starting up sensors, starting fan control:                                               done
> 0.07user 0.12system 0:00.55elapsed 35%CPU (0avgtext+0avgdata 0maxresident)k
> 24inputs+32outputs (0major+8664minor)pagefaults 0swaps
> 
> 20 milliseconds longer, AMD64 3200+ CPU, system ca 3y old, not top-top
> then.
> 
> I don't think I'd worry about it.

You tested on a system with only modules doing direct I/O access (it87
and k8temp). On a system with sensors on SMBus or I2C this is a totally
different story. For example, I just tested on my home server which
needs the lm85 and ds1621 drivers, unloading and reloading these takes
~360 ms. On top of that there can be hidden costs, many hwmon drivers
cache register values, when you cycle the drivers you lose the cache.

At the moment these drivers do not auto-load so the issue is
theoretical. But if they ever do, unloading and reloading them when we
don't have to will be a significant waste of time.

> > (...)
> > Going with the device paths (e.g. /sys/devices/platform/it87.656) works
> > well for platform devices, but it doesn't work that well for
> > SMBus-based chips, for the same reason hwmon class devices don't work:
> > i2c bus numbers aren't persistent. libsensors has a custom device
> > naming scheme which predates kernel 2.6 and udev, and solves all these
> > issues, unfortunately in user-space rather than at the kernel interface
> > level as udev does.
> > 
> > Getting fancontrol to do the same as sensors means either duplicating
> > the libsensors device naming logic there, or changing fancontrol to use
> > libsensors (meaning that you have to rewrite it in a different language
> > first, as a shell script can't use a C library.)
> 
> A wrapper for the library, which outputs device names to /sys/class/...
> pairs one per line in a format easily parsable by a shell script?

Either that, or with a command line interface so that you can ask
directly for what you want. This will save some parsing in user-space, and also avoids computing things that the caller will just discard.l

> > Or maybe an
> > intermediate solution would be a binary helper converting hwmon class
> > names to libsensors names and back.
> 
> Only the sensors names to filesystem names would really be needed.

I think both ways are needed. pwmconfig would need to convert hwmon# to
a libsensors name and use that name in /etc/fancontrol, and fancontrol
would need to convert the libsensors name to hwmon# to access the right
sysfs files.

> > As a side note, fancontrol started as a quick hack to get the fan
> > control job done. But it is showing its limits every now and then.
> 
> :)
> 
> I had to mess with it because for my mobo it was plain not working at
> all (useful PWM values 4..12, not 30..255).

Recent versions of pwmconfig handle this just fine, what was your
problem exactly?

Note that in many cases, small control ranges can be improved by
tweaking the PWM base frequency. Some of our drivers support that
already, in particular the it87 driver supports that since kernel
version 2.6.21.

> What I'd really like to write is a panel applet which does all of this:
> 
> * Monitor all hardware, this includes sensors as well as hard disks
> (smartmontools!).

I'd rather see a kernel driver exporting HDD temperature in the
standard hwmon format.

> * Control hardware as needed, e.g. fans, perhaps CPU performance.
> Applets for the CPU already exist.
> 
> * Warn if hardware goes pear-shaped, e.g. fans below min speed, disks
> failing or getting too hot, ..., by producing suitable popups,
> repeatedly as configured or clicked away by the user.
> 
> * With each warning, give information to users who don't have any
> hardware understanding, saying how serious the problem is nd what can be
> done about it.
> 
> * With mobo sensors I don't see the day where vendors will give decent
> info in a generic usable form. It's not happening with hard disks
> either, some smart info is plain shocking, also smart standards seem to
> be vague in places. The only workaround to that I can see is to have a
> component database, and have the application pull updates automatically
> say once a week.

Everybody is asking for this, but nobody seems to have the time to
actually make it happen.

> * There would need to be some GUI app to configure the lot first. Could
> be integrated with the applet of course. Similar in style to the superb
> kinternet from SUSE.
> 
> I like this in particular because neither Billyware nor Macsware have
> anything similar, and Linux could claim a user-friendly first.

Well, Windows has a number of third-party applications which do
basically what you described (SpeedFan for example.)

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Problem with order of module loading

[Jean Delvare]

Replying to myself...

On Mon, 26 Jan 2009 15:57:10 +0100, Jean Delvare wrote:
> On Mon, 26 Jan 2009 22:47:36 +1300, Volker Kuhlmann wrote:
> > A wrapper for the library, which outputs device names to /sys/class/...
> > pairs one per line in a format easily parsable by a shell script?
> 
> Either that, or with a command line interface so that you can ask
> directly for what you want. This will save some parsing in
> user-space, and also avoids computing things that the caller will
> just discard.

BTW, I forgot to mention: this won't solve the problem completely, as
the i2c bus numbers are still not stable. libsensors only addresses
this issue during configuration file parsing, where bus number
references can be bound to actual buses. But these statements have no
effect on the device names as returned by libsensors to applications.
This was the point of ticket #2238:

http://www.lm-sensors.org/ticket/2238

Unfortunately, the implementation I have in mind for ticket #2174 is
incompatible with the fact of letting bus statements have any effect
beyond the configuration file they come from:

http://www.lm-sensors.org/ticket/2174#comment:6

And I consider #2174 much more important to have than #2238, so the
latter will most certainly be closed as WONTFIX.

I tend to think that i2c bus number stability is better achieved at
kernel level anyway, maybe using the same approach used for multimedia
devices: a module parameter can be passed that specifies the desired
device number.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Problem with order of module loading

[Jean Delvare]

On Mon, 26 Jan 2009 15:57:10 +0100, Jean Delvare wrote:
> On Mon, 26 Jan 2009 22:47:36 +1300, Volker Kuhlmann wrote:
> > On Mon 26 Jan 2009 02:47:24 NZDT +1300, Jean Delvare wrote:
> > > I'm not sure why you think my approach wouldn't work. Let's take the
> > > case of your board: the k8temp driver loads automatically, the it87
> > > driver doesn't.
> > > 
> > > At first run, sensors-detect would stop the lm_sensors service (no
> > > effect as the service wasn't configured yet.) It would detect k8temp and
> > > it87, but seeing that k8temp is already loaded, would only list it87
> > > in /etc/sysconfig/lm_sensors.
> > > 
> > > At this point, starting the lm_sensors service only loads it87, because
> > > k8temp is already loaded. Likewise, stopping or restarting the
> > > lm_sensors service only unloads the it87 driver.
> > > 
> > > This means that a further run of sensors-detect will only unload the
> > > it87 driver. Then it will see that k8temp is loaded and again will not
> > > list it in /etc/sysconfig/lm_sensors.
> > 
> > Ah yes, put it like that, it should work. It would be very sensitive to
> > run-status being the same as boot-status though. Is this robust enough?
> 
> I agree it is a little fragile. It should work in the general case if
> the user doesn't edit the configuration file manually and doesn't load
> or unload hwmon drivers on its own. My hope is that users who start
> loading or unloading drivers or editing configuration files will know
> how to fix things if they break. But maybe that's too optimistic.

I have discussed this a bit with Kay Sievers yesterday. He suggested
that we can use the modalias files in sysfs together with "modprobe -n"
to find out whether a loaded hwmon driver has been auto-loaded or not.
This would let us exclude kernel modules from /etc/sysconfig/lm_sensors
based on whether they auto-load rather than based on whether they were
loaded when sensors-detect was run. This should be way more robust than
my initial proposal, to a point where I think it would make sense to
give it a try.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Problem with order of module loading

[Jean Delvare]

On Wed, 28 Jan 2009 09:06:28 +0100, Jean Delvare wrote:
> I have discussed this a bit with Kay Sievers yesterday. He suggested
> that we can use the modalias files in sysfs together with "modprobe -n"
> to find out whether a loaded hwmon driver has been auto-loaded or not.
> This would let us exclude kernel modules from /etc/sysconfig/lm_sensors
> based on whether they auto-load rather than based on whether they were
> loaded when sensors-detect was run. This should be way more robust than
> my initial proposal, to a point where I think it would make sense to
> give it a try.

Damn, it isn't as easy as I thought. Not all drivers follow the Linux
device driver model to the letter. Actually, most hwmon drivers do not,
because they create their own devices. Once such a driver is loaded, it
appears to be autoloading (its devices have modalias strings that point
to the driver) but in fact it is not. This fools my new code into
thinking that pretty much all loaded hwmon drivers were autoloaded.

Thus I fear I will have to limit the scope of my autoloading detection
code to PCI devices. At least this covers the k8temp driver, which is
probably the one that causes the more trouble in practice.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Problem with order of module loading

[Jean Delvare]

Volker,

On Fri, 30 Jan 2009 17:23:36 +0100, Jean Delvare wrote:
> On Wed, 28 Jan 2009 09:06:28 +0100, Jean Delvare wrote:
> > I have discussed this a bit with Kay Sievers yesterday. He suggested
> > that we can use the modalias files in sysfs together with "modprobe -n"
> > to find out whether a loaded hwmon driver has been auto-loaded or not.
> > This would let us exclude kernel modules from /etc/sysconfig/lm_sensors
> > based on whether they auto-load rather than based on whether they were
> > loaded when sensors-detect was run. This should be way more robust than
> > my initial proposal, to a point where I think it would make sense to
> > give it a try.
> 
> Damn, it isn't as easy as I thought. Not all drivers follow the Linux
> device driver model to the letter. Actually, most hwmon drivers do not,
> because they create their own devices. Once such a driver is loaded, it
> appears to be autoloading (its devices have modalias strings that point
> to the driver) but in fact it is not. This fools my new code into
> thinking that pretty much all loaded hwmon drivers were autoloaded.
> 
> Thus I fear I will have to limit the scope of my autoloading detection
> code to PCI devices. At least this covers the k8temp driver, which is
> probably the one that causes the more trouble in practice.

I have finally committed a change which should address your issue:
  http://www.lm-sensors.org/changeset/5635

Basically, PCI and USB drivers which are auto-loaded on a given system
are no longer listed in /etc/sysconfig/lm_sensors. That way,
"rclm_sensors restart" will not unload and reload drivers which are
already present at boot time. This is the best approach from a
performance point of view, and it is also stable across reconfiguration
(running sensors-detect twice doesn't change the outcome.)

Please give a try to:
  http://www.lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
and confirm that it solves your problem (k8temp should no longer be
listed, so the hwmon class device numbers should stay stable across
reboots.)

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors