OpenBSD manual page server

Manual Page Search Parameters
IPMI(4) Device Drivers Manual IPMI(4)

ipmi — Intelligent Platform Management Interface driver

ipmi0 at mainbus0
ipmi0 at acpi?
ipmi0 at iic?
ipmi0 at fdt?

The ipmi 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 command values.

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 systems processor(s).

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 can handle.

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 system interfaces.

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.
SMBus System Interface (SSIF)
The SSIF interface provides access to the BMC over an SMBus interface.

IPMI provides watchdog(4) timer 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:

# sysctl kern.watchdog.period=10

In this case if the watchdog is not reset, it'll reboot the server after roughly 10 seconds.

Example of disabling the watchdog:

# sysctl kern.watchdog.period=0

watchdog(4), sensorsd(8), sysctl(8)

The ipmi driver first appeared in OpenBSD 3.9 and conforms to the IPMI 1.5 specification.

The ipmi driver was written by Jordan Hargrave <jordan@openbsd.org>.

March 29, 2020 OpenBSD-current