IPMI(4) BSD Kernel Interfaces Manual IPMI(4)
ipmi -- Intelligent Platform Management Interface driver
ipmi0 at mainbus0
The ipmi term Intelligent Platform Management refers to autonomous moni-
toring 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
Platform status information can be obtained and recovery actions initi-
ated 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 proto-
col. IPMI request messages are commonly referred to as commands. The
use of request/response protocol facilitates the transfer of IPMI mes-
sages over different transports. IPMI commands are grouped into func-
tional 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 sta-
tus 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-
SYSTEM EVENT LOG AND EVENT MESSAGES
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.
SENSOR DATA RECORDS && CAPABILITIES COMMANDS
IPMI's extensibility and scalability mean that each platform implementa-
tion can have a different population of management controllers and sen-
sors and different event generation capabilities. The design of IPMI
allows system management software to retrieve information from the plat-
form and automatically configure itself to the platform's capabilities.
Information that describes the platform management capabilities is pro-
vided 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 func-
tions 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 han-
dle 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 microcon-
troller. The term "Keyboard Controller Style" reflects the fact
that the 8742 interface was used as the legacy keyboard con-
troller 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 inter-
face, 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 hand-
shake 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) 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 recov-
erability 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
The ipmi driver was written by Jordan Hargrave <firstname.lastname@example.org>.
BSD April 30, 2017 BSD