All of lore.kernel.org
 help / color / mirror / Atom feed
From: lmsensors@kosowsky.org
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes
Date: Sun, 08 Apr 2007 20:17:31 +0000	[thread overview]
Message-ID: <m2irc6vcx0.fsf@consult.pretender> (raw)
In-Reply-To: <4615F494.6070403@hhs.nl>

On 06 Apr 2007 13:21:59 -0400, jk wrote:
> > I am then surprised that many more people are not having this
> > problem. It would seem then that this "race condition" would apply to
> > anybody who had more than one i2c bus.
> 
> Let me guess, your kernel is compiled with
> CONFIG_PCI_MULTITHREAD_PROBE=y?
 
I don't know. I am using a standard Fedora Core 2.6.20 kernel and I
don't see that option name in the top level .config file. Should I be
looking elsewhere in the tree for that variable name?
 
> > Perhaps though there are not many people who are using sensord/rrd
> > though... (however, if you are and set up the crontab as recommended
> > then you will get cron email errors mailed to you every 5 minutes :)
> 
> First of all, the right way to look for hardware monitoring devices
> on a reasonably recent Linux 2.6 kernel is through /sys/class/hwmon.
> Historically, tools have been assuming that hardware monitoring devices
> were always presented as I2C devices and looked for them
> in /sys/bus/i2c/devices, but this is no longer correct. Granted though,
> libsensors still identifies i2c devices using their i2c device names
> internally. Maybe we'll need to change that someday. That being said,
> it moves the problem more than it solves it, when more than one
> hardware monitoring device is present on a system (which becomes more
> frequent these days.)

That is good to know about /sys/class/hwmon since that will presumably
solve my problems directly. 

I think though that part of the problem is that many of the user-space
programs and documentation in the lm_sensors tarball (at least in
version 2.10.1) are not updated for recent 2.6 kernels.

For example, the program sens_update_rrd looks in either
/proc/sys/dev/sensors (which is obsolete) or in /sys/bus/i2c/devices
(which gives the problems I have).

Instead it should just go to /sys/class/hwmon and be done with it!

Also, just as a random example, the documentation for sensors.conf
when discussing about the BUS STATEMENT (which I found by your reference
below) only talks about /proc/bus/i2c which is obsolete for 2.6
kernels. Similarly, it references the program
prog/config/grab_busses.sh which only works in 2.4 kernels.

So, I guess the better question is whether anybody plans on updating
the documentation and auxiliary programs in the lm_sensors tarball to
reflect 2.6 kernels in general and "later" 2.6 kernels in particular.

> Secondly, libsensors supports consistent i2c bus numbering for years,
> for specific-device configuration sections. See the "BUS STATEMENT"
> section in sensors.conf(5).
> 
> This doesn't cover all cases, but these are things to keep in mind when
> facing device naming issues.
> 
> -- 
> Jean Delvare
> 


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

  parent reply	other threads:[~2007-04-08 20:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-06  7:19 [lm-sensors] asb_100 sensor location in /sys heirarchy changes Hans de Goede
2007-04-06 15:52 ` jk
2007-04-06 16:21 ` Hans de Goede
2007-04-06 17:21 ` jk
2007-04-06 18:10 ` jk
2007-04-06 18:51 ` Hans de Goede
2007-04-06 18:57 ` Hans de Goede
2007-04-08 17:50 ` Jean Delvare
2007-04-08 18:40 ` Jean Delvare
2007-04-08 18:42 ` Hans de Goede
2007-04-08 18:49 ` Hans de Goede
2007-04-08 20:17 ` lmsensors [this message]
2007-04-09 10:06 ` Jean Delvare
2007-04-09 11:01 ` Jean Delvare
2007-04-17  9:19 ` Jean Delvare
2007-04-17 13:34 ` Jeffrey J. Kosowsky
2007-04-17 19:02 ` Jean Delvare
2007-04-17 20:52 ` Jeffrey J. Kosowsky
2007-04-19 18:35 ` Jean Delvare
2007-04-19 18:50 ` Jeffrey J. Kosowsky
2007-04-23  5:38 ` Jean Delvare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2irc6vcx0.fsf@consult.pretender \
    --to=lmsensors@kosowsky.org \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.