CHAPTER 8. SENSORS
formulas. OpenIPMI implements all these and provides ways for OEM functions to plug in to provide their own converters. If you have a sensor that cannot be represented using the standard mechanisms, you need to get the OEM algorithms for this and implement them in an OEM plug-in for the sensor.
You may have events on a threshold sensor by specifying values (called thresholds) where you want the sensor to report an event. Then you can enable the events for the specific thresholds. Not all sensors support all thresholds, some cannot have their events enabled and others cannot have them disabled. The capabilities of a sensor may all be queried by the user to determine what it can do. When the value of the sensor goes outside the threshold an event may be generated. An event may be generated when the value goes back into the threshold.
Events for threshold sensors are mind-bogglingly complicated. Each threshold has four different possible events that can be supported. Only two of them make sense to support for any given threshold, thankfully. And a sensor can have six different thresholds.
IPMI supports events on going below (going low) the threshold and going above the threshold (going high). For each of those, it supports an assertion and deassertion event. Most sensors are either a lower bound (and would thus support an eventgoing below the threshold) or an upper bound (and would thus support an event going above the threshold). Figure 8.1 on the next page shows an upper and lower threshold sensor. When the value of an upper threshold sensor goes above the threshold, that is an assertion going high. When it goes back below the threshold, that is a deassertion going high. On a lower threshold, going below the threshold is a assertion going low. When the value goes back above the threshold, it is an deassertion going low.
Each sensor may have six different thresholds: upper non-recoverable upper critical upper non-critical lower non-critical lower critical lower non-recoverable The meanings of these are not defined by IPMI, but the meanings are pretty obvious. You may ask, though, why there are both upper and lower thresholds and separate going high and going low events. A going low event is kind of silly on an upper threshold, for instance. The reasoning is not in the spec, but it may be that there are sensors where the “middle” of the range is not ok. So for instance, it may be ok if the temperature is above 100C or below 5C, but the range between those values is not ok. This is extremely unlikely, but this type of structure allows it.
Threshold sensors may have hysteresis, meaning that when the threshold goes on above or below the specified value, the transition point where the threshold goes off is somewhat below or above the given value. For instance, if you want a fan speed sensor to go off when it goes below 150 RPM, if the fan is hanging right around 150 RPM, the sensor may be constantly sending you events as it goes slightly above and slightly below 150 RPM, which is bad because it can overload the system management software. The hysteresis for the fan might be set at 10 rpm, which means that if the speed goes below 150 RPM, then it must go above 160 RPM for the threshold to be disabled. Hysteresis may be settable or may be fixed for the sensor.