xref: /openbsd-src/share/man/man4/ipmi.4 (revision 99fd087599a8791921855f21bd7e36130f39aadc)
1.\"	$OpenBSD: ipmi.4,v 1.14 2019/08/19 18:56:23 kettenis Exp $
2.\"
3.\" Copyright (c) 2005 Marco Peereboom <marco@openbsd.org>
4.\" Text was heavily borrowed from the IPMI spec V1.5
5.\"
6.\" Permission to use, copy, modify, and distribute this software for any
7.\" purpose with or without fee is hereby granted, provided that the above
8.\" copyright notice and this permission notice appear in all copies.
9.\"
10.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
11.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
12.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
13.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
14.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
15.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
16.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
17.Dd $Mdocdate: August 19 2019 $
18.Dt IPMI 4
19.Os
20.Sh NAME
21.Nm ipmi
22.Nd Intelligent Platform Management Interface driver
23.Sh SYNOPSIS
24.Cd "ipmi0 at mainbus0"
25.Cd "ipmi0 at acpi?"
26.Cd "ipmi0 at iic?"
27.Sh DESCRIPTION
28The
29.Nm
30term Intelligent Platform Management refers to autonomous monitoring and
31recovery features implemented directly in platform management hardware and
32firmware.
33The key characteristics of Intelligent Platform Management is that
34inventory, monitoring, logging, and recovery control functions are available
35independent of the main processor, BIOS, and operating system.
36.Pp
37Platform status information can be obtained and recovery actions initiated
38under situations where vendor "in-band" management mechanisms are unavailable.
39The independent monitoring, logging, and access functions available through IPMI
40provide a level of manageability built in to the platform hardware.
41This can support systems where there is no systems management software
42available for a particular operating system.
43.Pp
44At the heart of the IPMI architecture is a microcontroller called
45the Baseboard Management Controller (BMC).
46The BMC provides the intelligence behind Intelligent Platform Management.
47The BMC manages the interface between system management software
48and the platform management hardware, provides autonomous monitoring,
49event logging, and recovery control and serves as the gateway
50between systems management software and hardware.
51.Sh IPMI MESSAGING
52IPMI uses message-based interfaces for the different interfaces to the platform
53management subsystems.
54All IPMI messages share the same fields in the message "payload",
55regardless of the interface (transport) that they're transferred over.
56IPMI messaging uses a request/response protocol.
57IPMI request messages are commonly referred to as commands.
58The use of request/response protocol facilitates the transfer of
59IPMI messages over different transports.
60IPMI commands are grouped into functional command sets
61using a field called network function code.
62There are command sets for sensor and event related commands,
63chassis commands etc.
64This functional grouping makes it easier to organize and manage
65the assignment and allocation of command values.
66.Sh SENSOR MODEL
67Access to monitored information such as temperatures, voltages, fan status
68etc., is provided via the IPMI Sensor Model.
69Instead of providing direct access to the monitoring hardware,
70IPMI provides access by abstracted sensor commands
71such as the "Get Sensor Reading" command,
72implemented via a management controller.
73This approach isolates the software from changes in the
74platform management hardware implementation.
75.Pp
76Sensors are classified according to the type of readings they provide
77and/or the type of events they generate.
78A sensor can return either an analog or discrete reading.
79Sensor events can be discrete or threshold-based.
80.Sh SYSTEM EVENT LOG AND EVENT MESSAGES
81The BMC provides a centralized non-volatile System Event Log, or SEL.
82Having the SEL and logging functions managed by the BMC
83helps ensure that post-mortem logging information is available
84should a failure occur that disables the systems processor(s).
85.Pp
86A set of IPMI commands allows the SEL to be read and cleared
87and for events to be added to the SEL.
88The common request message (command)
89used for adding events to the SEL is referred to as an Event Message.
90.Sh SENSOR DATA RECORDS & CAPABILITIES COMMANDS
91IPMI's extensibility and scalability mean that
92each platform implementation can have
93a different population of management controllers and sensors and
94different event generation capabilities.
95The design of IPMI allows system
96management software to retrieve information from the platform
97and automatically configure itself to the platform's capabilities.
98.Pp
99Information that describes the platform management capabilities
100is provided via two mechanisms:
101Capabilities Commands and Sensor Data Records (SDRs).
102Capabilities commands are commands within the IPMI command sets that return
103fields that provide information on other commands and functions the controller
104can handle.
105.Sh SYSTEMS INTERFACES
106IPMI defines three standardized systems interfaces that systems software uses
107for transferring IPMI messages to the BMC.
108In order to support a variety of microcontrollers,
109IPMI offers a choice of systems interfaces.
110The system interfaces are similar enough so that
111a single driver can handle all IPMI system interfaces.
112.Bl -tag -width Ds
113.It Keyboard Controller Style (KCS)
114The bit definitions and operation of the registers follows that used in the
115Intel 8742 Universal Peripheral Interface microcontroller.
116The term "Keyboard Controller Style" reflects the fact that
117the 8742 interface was used as the legacy keyboard controller interface
118in PC architecture computer systems.
119This interface is available built in to several commercially available
120microcontrollers.
121Data is transferred across the KCS interface using a per-byte handshake.
122.It System Management Interface Chip (SMIC)
123The SMIC interface provides an alternative
124when the implementer wishes to use a microcontroller for the BMC
125that does not have the built-in hardware for a KCS interface.
126This interface is a three I/O port interface that can be
127implemented using a simple ASIC, FPGA, or discrete logic devices.
128It may also be built in to a custom-designed management controller.
129Like the KCS interface,
130a per-byte handshake is also used
131for transferring data across the SMIC interface.
132.It Block Transfer (BT)
133This interface provides a higher performance system interface option.
134Unlike the KCS and SMIC interfaces,
135a per-block handshake is used for transferring data across the interface.
136The BT interface also provides an alternative to using
137a controller with a built-in KCS interface.
138The BT interface has three I/O mapped ports.
139A typical implementation includes hardware buffers for holding
140upstream and downstream message blocks.
141The BT interface can be implemented using an ASIC or FPGA
142or may be built in to a custom-designed management controller.
143.It SMBus System Interface (SSIF)
144The SSIF interface provides access to the BMC over an SMBus interface.
145.El
146.Sh WATCHDOG
147IPMI provides
148.Xr watchdog 4
149timer functionality.
150Once configured, if the watchdog is not reset within
151a certain period of time,
152it will timeout and the server will reset.
153The reset will occur regardless of the recoverability of the hang or crash.
154.Pp
155Example of enabling a watchdog:
156.Pp
157.Dl # sysctl kern.watchdog.period=10
158.Pp
159In this case if the watchdog is not reset,
160it'll reboot the server after roughly 10 seconds.
161.Pp
162Example of disabling the watchdog:
163.Pp
164.Dl # sysctl kern.watchdog.period=0
165.Sh SEE ALSO
166.Xr watchdog 4 ,
167.Xr sensorsd 8 ,
168.Xr sysctl 8
169.Sh HISTORY
170The
171.Nm
172driver first appeared in
173.Ox 3.9
174and conforms to the IPMI 1.5 specification.
175.Sh AUTHORS
176The
177.Nm
178driver was written by
179.An Jordan Hargrave Aq Mt jordan@openbsd.org .
180