Penguin Computing Relion 1900e, Technical Manual

Page: 78 / 174

Relion 1900e/2900e Manual
63 Revision 1.3
system state changes by maintaining virtual sensors that are not specifically tied to physical hardware. This
section describes general aspects of BMC sensor management as well as describing how specific sensor
types are modeled. Unless otherwise specified, the term “sensor” refers to the IPMI sensor-model definition
of a sensor.
7.3.1 Sensor Scanning
The value of many of the BMC’s sensors is derived by the BMC FW periodically polling physical sensors in the
system to read temperature, voltages, and so on. Some of these physical sensors are built in to the BMC
component itself and some are physically separated from the BMC. Polling of physical sensors for support of
IPMI sensor monitoring does not occur until the BMC’s operational code is running and the IPMI FW
subsystem has completed initialization. IPMI sensor monitoring is not supported in the BMC boot code.
Additionally, the BMC selectively polls physical sensors based on the current power and reset state of the
system and the availability of the physical sensor when in that state. For example, non-standby voltages are
not monitored when the system is in a S5 power state.
7.3.2 Sensor Rearm Behavior
7.3.2.1 Manual versus Re-arm Sensors
Sensors can be either manual or automatic re-arm. An automatic re-arm sensor will "re-arm" (clear) the
assertion event state for a threshold or offset if that threshold or offset is de-asserted after having been
asserted. This allows a subsequent assertion of the threshold or an offset to generate a new event and
associated side-effect. An example side-effect would be boosting fans due to an upper critical threshold
crossing of a temperature sensor. The event state and the input state (value) of the sensor track each other.
Most sensors are auto-rearm.
A manual re-arm sensor does not clear the assertion state even when the threshold or offset becomes de-
asserted. In this case, the event state and the input state (value) of the sensor do not track each other. The
event assertion state is "sticky". The following methods can be used to re-arm a sensor:
•
Automatic re-arm – Only applies to sensors that are designated as “auto-rearm”.
• IPMI command Re-arm Sensor Event
•
BMC internal method – The BMC may re-arm certain sensors due to a trigger condition. For example, some
sensors may be re-armed due to a system reset. A BMC reset will re-arm all sensors.
• System reset or DC power cycle will re-arm all system fan sensors.
7.3.2.2 Re-arm and Event Generation
All BMC-owned sensors that show an asserted event status generate a de-assertion SEL event when the
sensor is re-armed, provided that the associated SDR is configured to enable a de-assertion event for that
condition. This applies regardless of whether the sensor is a threshold/analog sensor or a discrete sensor.
To manually re-arm the sensors, the sequence is outlined below:
1. A failure condition occurs and the BMC logs an assertion event.
2. If this failure condition disappears, the BMC logs a de-assertion event (if so configured.)
3. The sensor is re-armed by one of the methods described in the previous section.
4. The BMC clears the sensor status.
5. The sensor is put into "reading-state-unavailable" state until it is polled again or otherwise updated.
6. The sensor is updated and the “reading-state-unavailable” state is cleared. A new assertion event will
be logged if the fault state is once again detected.