Provided by: lm-sensors_3.0.0-4ubuntu1_i386 bug


       sensors.conf - libsensors configuration file


       sensors.conf  describes  how  libsensors, and so all programs using it,
       should translate the raw readings from the kernel modules to real-world


       Comments  are  introduces by hash marks. A comment continues to the end
       of the line. Empty lines,  and  lines  containing  only  whitespace  or
       comments  are  ignored.  Other lines have one of the below forms. There
       must be whitespace between each element, but the amount  of  whitespace
       is  unimportant.  A line may be continued on the next line by ending it
       with a backslash; this does not work within a comment, NAME or  NUMBER.

              bus NAME NAME NAME
              chip NAME-LIST
              label NAME NAME
              compute NAME EXPR , EXPR
              ignore NAME
              set NAME EXPR

       A   NAME  is  a  string.  If  it  only  contains  letters,  digits  and
       underscores, it does not have to quoted; in all other cases, you should
       use  double  quotes  around  it.  Within quotes, you can use the normal
       escape-codes from C.

       A NAME-LIST is one or more NAME items behind each other,  separated  by

       A EXPR is of one of the below forms:

              EXPR + EXPR
              EXPR - EXPR
              EXPR * EXPR
              EXPR / EXPR
              - EXPR
              ( EXPR )

       A NUMBER is a floating-point number. ‘10’, ‘10.4’ and ‘.4’ are examples
       of valid floating-point numbers; ‘10.’ or ‘10E4’ are not valid.


       This section describes the meaning of each statement. Each statement is
       accompanied by an example line. Please ignore line wrap-arounds.

              bus "i2c-0" "SMBus PIIX4 adapter at e800"

       A  bus  statement binds the description of an I2C or SMBus adapter to a
       bus number.  This makes it possible to  refer  to  an  adapter  in  the
       configuration  file,  independent  of  the actual correspondence of bus
       numbers and actual adapters (which may change from moment to moment).

       The first argument is the bus number. It  is  the  literal  text  i2c-,
       followed  by  a  number.  As  there is a dash in this argument, it must
       always be quoted.

       The second argument is the adapter name,  it  must  match  exactly  the
       adapter  name  as  it appears in /sys/class/i2c-adapter/i2c-*/name.  It
       should always be quoted as well  as  it  will  most  certainly  contain
       spaces or dashes.

       The   bus   statements   may   be  scattered  randomly  throughout  the
       configuration file; there is no need to place the bus line  before  the
       place  where  its  binding  is  referred to. Still, as a matter of good
       style, we suggest you place all bus statements together at the  top  of
       your configuration file.

       Running sensors --bus-list will generate these lines for you.

              chip "lm78-*" "lm79-*"

       The  chip statement selects for which chips all following configuration
       statements are meant. The chip selection remains valid until  the  next
       chip statement. It does not influence the operation of a bus statement.

       If a chip matches at least one of the chip descriptions, all  following
       configuration lines are examined for it. If it matches none of the chip
       descriptions, every non-bus statement is ignored  upto  the  next  chip

       A  chip  description  is  built from a couple of elements, separated by

       The first element is the name of the  chip  type.  Sometimes  a  single
       driver  implements  several  chip types, with several names. The driver
       documentation should tell you. You may substitute the wildcard operator
       * for this element.

       The  second  element is the name of the bus. This is either isa, pci or
       i2c-N, with N being any number as binded with a bus statement. You  may
       substitute  the  wildcard  operator * for this element, or only for the
       number of the I2C bus (which means ’any I2C bus’).

       The third element is the hexadecimal address of  the  chip.  The  valid
       range depends on the bus type. You may substitute the wildcard operator
       * for this element.

       Note that it wouldn’t make any sense to specify the address without the
       bus  type.  For this reason, the address part is plain omitted when the
       bus type isn’t specified.   The  following  are  all  valid  chip  type
       specification based on lm78-i2c-1-2d or lm78-isa-0290:


              compute in3 ((6.8/10)+1)*@ ,  @/((6.8/10)+1)

       The  compute  statement  describes how you should translate a feature’s
       raw value to a real-world value, and how you should translate  it  back
       to a raw value again.

       The  first  argument  is  the  feature name, which may be the name of a
       feature class (see below). The second is an expression which  specifies
       how  a  raw  value must be translated to a real-world value; ‘@’ stands
       here for the raw value. The third is an expression that specifies how a
       real-world  value  should be translated back to a raw value; ‘@’ stands
       here for the real-world value.

       You may use the name of other features in these expressions; you should
       be  careful  though  to avoid circular references, as this may hang the
       expression evaluator.

       If at any moment a translation between a raw and a real-world value  is
       called  for, but no compute statement applies, a one-on-one translation
       is used instead.

       The comma is an  unfortunate  necessity  to  stop  the  statement  from
       becoming ambiguous.

              ignore fan1

       The  ignore  statement  is  a  hint  that  a specific feature should be
       ignored - probably  because  it  returns  bogus  values  (for  example,
       because a fan or temperature sensor is not connected).

       The only argument is the feature name, which may be a feature class; in
       that case the label class is used (see below).

              label in3 "+5V"

       The label statement describes how a feature should be called.  Features
       without  a  label  statement  are  just  called  by their feature name.
       Applications can use this to label the readings they present (but  they
       don’t have to).

       The  first  argument  is the feature name, which may be a feature class
       (see below). The second argument is the feature description.

              set in3_min  5 * 0.95

       The set statement gives an  initial  value  for  a  feature.  Not  each
       feature  can  be  given  a  sensible  initial value; valid features are
       usually min/max limits.

       The first argument is the feature  name.  The  second  argument  is  an
       expression  which determines the initial value. If there is an applying
       compute statement, this value is fed to its third argument to translate
       it to a raw value.

       You  may  use  the name of other features in these expressions; current
       readings are  substituted.  You  should  be  careful  though  to  avoid
       circular  references,  as this may hang the expression evaluator. Also,
       you can’t be sure in which order set statements are evaluated, so  this
       can lead to nasty surprises.


       There  are two kinds of classes, here called compute and label classes,
       after the statements for which they are defined.  Classes  are  defined
       over  features:  the  kind of values that can be read from or set for a
       specific kind of chip.

       Each class has a class name, which is usually  the  same  as  its  most
       prominent  feature.  A  label  or  compute statement for the class name
       feature forces the  same  settings  for  all  other  class  members.  A
       specific  statement  for  a  class  member feature always overrides the
       general class setting, though. This means that you can’t  override  the
       class name feature explicitly.

       A  simple example will explain this better. The fan1 label class of the
       lm78 chip contains three members: fan1 itself, fan1_min  and  fan1_div.
       The last feature sets the number by which readings are divided (to give
       the fan  less  resolution,  but  a  larger  field  of  operation).  The
       following  line will set the name of all these features to describe the
              label fan1 "Processor 1 FAN"
       Now we happen to know that, due to the type of fan we use, all readings
       are  always  off  by  a factor of two (some fans only return one ’tick’
       each rotation, others return two):
              compute fan1 @/2 , @*2
       It will be clear that this should be done for the fan1_min feature too,
       but  not  for the fan1_div feature! Fortunately, the fan1 compute class
       contains fan1_min, but not fan1_div, so this works out right.


       If more than one statement of  the  same  kind  applies  at  a  certain
       moment, the last one in the configuration file is used. So usually, you
       should put more genereal  chip  statements  at  the  top,  so  you  can
       overrule them below.

       There  is  one  exception  to  this  rule:  if a statement only applies
       because the feature is in the same class as the feature  the  statement
       contains,  and  there  is  anywhere  else a statement for this specific
       class member, that one takes always precedence.


              The    system-wide     libsensors(3)     configuration     file.
              /etc/sensors3.conf  is  tried  first,  and  if it doesn’t exist,
              /etc/sensors.conf is used instead.




       Frodo Looijaard and the lm_sensors group