The /usr/local/etc/freeipmi/freeipmi_interpret_sensor.conf
defines how IPMI sensors should be interpreted. IPMI based sensors specify a
number of states/thresholds when they are read. Based on those
states/thresholds, libraries and tools such as libfreeipmi(3),
libipmimonitoring(3) and ipmi-sensors(8) can report if a
sensor reading is "good" or "bad" via a report of a
NOMINAL, WARNING, or CRITICAL state.
Each of the states listed below are (hopefully) descriptive enough
to describe the state conditions that may be set/unset for each sensor type.
For more detailed information on each of the individual states listed below,
please see the IPMI Specification "Sensor and Event Code Tables".
Ipmi-sensors(8) can be used to determine the sensor types and the
states/thresholds that exist on a system by outputting very verbose output
and seeing what types of Assertion or Deassertion events are possible.
The possible values for all states/thresholds below are:
Nominal - Signal Nominal reading if state/threshold tripped
Warning - Signal Warning reading if state/treshold tripped
Critical - Signal Critical reading if state/threshold tripped
Not all IPMI sensor types and event types are currently supported.
If you would like more to be supported, please e-mail the FreeIPMI mailing
list.
The default values selected for individual states/thresholds being
tripped are based on best guesses and motherboards being analyzed. If you
think they should be changed, please e-mail the FreeIPMI mailing list to
discuss what the defaults should be.
Most default interpretations can be determined quite easily and
can meet the needs of most users. For example, a reading of
"Performance_Met" is normally better than
"Performance_Lags". However, some sensors can be ambiguous and
depend completely on the manufacturer. For example,
"State_Asserted" vs. "State_Deasserted" are completely
at the interpretation of the vendor. Users are advised to adjust the
interpretations below as needed for their machines.
Every group of state conditions below includes a configuration for
"No_Event". This is the condition under which no sensor
states/events have occurred or are triggered. Under most conditions, a
mapping to "Nominal" is preferred. However, under some
circumstances, it may be useful to report something else. For example, if a
sensor on a particular motherboard is required to report a state/event, a no
sensor state condition could indicate a broken a sensor. This is highly
dependent on the motherboard.