IPMI(4) OpenBSD Programmer's Manual IPMI(4)NAMEipmi - Intelligent Platform Management Interface driver
SYNOPSIS
ipmi0 at mainbus0
DESCRIPTION
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 MESSAGING
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.
SENSOR MODEL
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.
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
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.
SYSTEMS INTERFACES
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.
WATCHDOG
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
SEE ALSOwatchdog(4), sensorsd(8), sysctl(8)HISTORY
The ipmi driver first appeared in OpenBSD 3.9 and conforms to the IPMI
1.5 specification.
AUTHORS
The ipmi driver was written by Jordan Hargrave <jordan@openbsd.org>.
OpenBSD 4.9 March 22, 2010 OpenBSD 4.9
