Intelligent Platform Management Interface
ipmi0 at mainbus0
TABLE OF CONTENTS
term Intelligent Platform Management
refers to autonomous monitoring and recovery features implemented directly in
platform management hardware and firmware. The key characteristics of
Intelligent Platform Management is that inventory, monitoring, logging, and
recovery control functions are available independent of the main processor,
BIOS, and operating system.
Platform status information can be obtained and recovery actions initiated under
situations where vendor "in-band" management mechanisms are
unavailable. The independent monitoring, logging, and access functions
available through IPMI provide a level of manageability built in to the
platform hardware. This can support systems where there is no systems
management software available for a particular operating system.
At the heart of the IPMI architecture is a microcontroller called the Baseboard
Management Controller (BMC). The BMC provides the intelligence behind
Intelligent Platform Management. The BMC manages the interface between system
management software and the platform management hardware, provides autonomous
monitoring, event logging, and recovery control and serves as the gateway
between systems management software and hardware.
IPMI uses message-based interfaces for the different interfaces to the platform
management subsystems. All IPMI messages share the same fields in the message
"payload", regardless of the interface (transport) that they're
transferred over. IPMI messaging uses a request/response protocol. IPMI
request messages are commonly referred to as commands. The use of
request/response protocol facilitates the transfer of IPMI messages over
different transports. IPMI commands are grouped into functional command sets
using a field called network function code. There are command sets for sensor
and event related commands, chassis commands etc. This functional grouping
makes it easier to organize and manage the assignment and allocation of
Access to monitored information such as temperatures, voltages, fan status etc.,
is provided via the IPMI Sensor Model. Instead of providing direct access to
the monitoring hardware, IPMI provides access by abstracted sensor commands
such as the "Get Sensor Reading" command, implemented via a
management controller. This approach isolates the software from changes in the
platform management hardware implementation.
Sensors are classified according to the type of readings they provide and/or the
type of events they generate. A sensor can return either an analog or discrete
reading. Sensor events can be discrete or threshold-based.
The BMC provides a centralized non-volatile System Event Log, or SEL. Having the
SEL and logging functions managed by the BMC helps ensure that post-mortem
logging information is available should a failure occur that disables the
A set of IPMI commands allows the SEL to be read and cleared and for events to
be added to the SEL. The common request message (command) used for adding
events to the SEL is referred to as an Event Message.
IPMI's extensibility and scalability mean that each platform implementation can
have a different population of management controllers and sensors and
different event generation capabilities. The design of IPMI allows system
management software to retrieve information from the platform and
automatically configure itself to the platform's capabilities.
Information that describes the platform management capabilities is provided via
two mechanisms: Capabilities Commands and Sensor Data Records (SDRs).
Capabilities commands are commands within the IPMI command sets that return
fields that provide information on other commands and functions the controller
IPMI defines three standardized systems interfaces that systems software uses
for transferring IPMI messages to the BMC. In order to support a variety of
microcontrollers, IPMI offers a choice of systems interfaces. The system
interfaces are similar enough so that a single driver can handle all IPMI
- Keyboard Controller Style (KCS)
- The bit definitions and operation of the registers follows that used in
the Intel 8742 Universal Peripheral Interface microcontroller. The term
"Keyboard Controller Style" reflects the fact that the 8742
interface was used as the legacy keyboard controller interface in PC
architecture computer systems. This interface is available built in to
several commercially available microcontrollers. Data is transferred
across the KCS interface using a per-byte handshake.
- System Management Interface Chip (SMIC)
- The SMIC interface provides an alternative when the implementer wishes to
use a microcontroller for the BMC that does not have the built-in hardware
for a KCS interface. This interface is a three I/O port interface that can
be implemented using a simple ASIC, FPGA, or discrete logic devices. It
may also be built in to a custom-designed management controller. Like the
KCS interface, a per-byte handshake is also used for transferring data
across the SMIC interface.
- Block Transfer (BT)
- This interface provides a higher performance system interface option.
Unlike the KCS and SMIC interfaces, a per-block handshake is used for
transferring data across the interface. The BT interface also provides an
alternative to using a controller with a built-in KCS interface. The BT
interface has three I/O mapped ports. A typical implementation includes
hardware buffers for holding upstream and downstream message blocks. The
BT interface can be implemented using an ASIC or FPGA or may be built in
to a custom-designed management controller.
IPMI provides watchdog(4)
functionality. Once configured, if the watchdog is not reset within a certain
period of time, it will timeout and the server will reset. The reset will
occur regardless of the recoverability of the hang or crash.
Example of enabling a watchdog:
In this case if the watchdog is not reset, it'll reboot the server after roughly
Example of disabling the watchdog:
driver first appeared in
and conforms to the IPMI 1.5
driver was written by