요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
=====================
The Linux IPMI Driver
=====================
:Author: Corey Minyard <[email protected]> / <[email protected]>
The Intelligent Platform Management Interface, or IPMI, is a
standard for controlling intelligent devices that monitor a system.
It provides for dynamic discovery of sensors in the system and the
ability to monitor the sensors and be informed when the sensor's
values change or go outside certain boundaries. It also has a
standardized database for field-replaceable units (FRUs) and a watchdog
timer.
To use this, you need an interface to an IPMI controller in your
system (called a Baseboard Management Controller, or BMC) and
management software that can use the IPMI system.
This document describes how to use the IPMI driver for Linux. If you
are not familiar with IPMI itself, see the web site at
https://www.intel.com/design/servers/ipmi/index.htm. IPMI is a big
subject and I can't cover it all here!
Configuration
-------------
The Linux IPMI driver is modular, which means you have to pick several
things to have it work right depending on your hardware. Most of
these are available in the 'Character Devices' menu then the IPMI
menu.
No matter what, you must pick 'IPMI top-level message handler' to use
IPMI. What you do beyond that depends on your needs and hardware.
The message handler does not provide any user-level interfaces.
Kernel code (like the watchdog) can still use it. If you need access
from userland, you need to select 'Device interface for IPMI' if you
want access through a device driver.
The driver interface depends on your hardware. If your system
properly provides the SMBIOS info for IPMI, the driver will detect it
and just work. If you have a board with a standard interface (These
will generally be either "KCS", "SMIC", or "BT", consult your hardware
manual), choose the 'IPMI SI handler' option. A driver also exists
for direct I2C access to the IPMI management controller. Some boards
support this, but it is unknown if it will work on every board. For
this, choose 'IPMI SMBus handler', but be ready to try to do some
figuring to see if it will work on your system if the SMBIOS/ACPI
information is wrong or not present. It is fairly safe to have both
these enabled and let the drivers auto-detect what is present.
You should generally enable ACPI on your system, as systems with IPMI
can have ACPI tables describing them.
If you have a standard interface and the board manufacturer has done
their job correctly, the IPMI controller should be automatically
detected (via ACPI or SMBIOS tables) and should just work. Sadly,
many boards do not have this information. The driver attempts
standard defaults, but they may not work. If you fall into this
situation, you need to read the section below named 'The SI Driver' or
"The SMBus Driver" on how to hand-configure your system.
IPMI defines a standard watchdog timer. You can enable this with the
'IPMI Watchdog Timer' config option. If you compile the driver into
the kernel, then via a kernel command-line option you can have the
watchdog timer start as soon as it initializes. It also has a lot
of other options, see the 'Watchdog' section below for more details.
Note that you can also have the watchdog continue to run if it is
closed (by default it is disabled on close). Go into the 'Watchdog
Cards' menu, enable 'Watchdog Timer Support', and enable the option
'Disable watchdog shutdown on close'.
IPMI systems can often be powered off using IPMI commands. Select
'IPMI Poweroff' to do this. The driver will auto-detect if the system
can be powered off by IPMI. It is safe to enable this even if your
system doesn't support this option. This works on ATCA systems, the
Radisys CPI1 card, and any IPMI system that supports standard chassis
management commands.
If you want the driver to put an event into the event log on a panic,
enable the 'Generate a panic event to all BMCs on a panic' option. If
you want the whole panic string put into the event log using OEM
events, enable the 'Generate OEM events containing the panic string'
option. You can also enable these dynamically by setting the module
parameter named "panic_op" in the ipmi_msghandler module to "event"
or "string". Setting that parameter to "none" disables this function.
Basic Design
------------
The Linux IPMI driver is designed to be very modular and flexible, you
only need to take the pieces you need and you can use it in many
different ways. Because of that, it's broken into many chunks of
code. These chunks (by module name) are:
ipmi_msghandler - This is the central piece of software for the IPMI
system. It handles all messages, message timing, and responses. The
IPMI users tie into this, and the IPMI physical interfaces (called
System Management Interfaces, or SMIs) also tie in here. This
provides the kernelland interface for IPMI, but does not provide an
interface for use by application processes.
ipmi_devintf - This provides a userland IOCTL interface for the IPMI
driver, each open file for this device ties in to the message handler
as an IPMI user.
ipmi_si - A driver for various system interfaces. This supports KCS,
SMIC, and BT interfaces. Unless you have an SMBus interface or your
own custom interface, you probably need to use this.
ipmi_ssif - A driver for accessing BMCs on the SMBus. It uses the
I2C kernel driver's SMBus interfaces to send and receive IPMI messages
over the SMBus.
ipmi_powernv - A driver for access BMCs on POWERNV systems.
ipmi_watchdog - IPMI requires systems to have a very capable watchdog
timer. This driver implements the standard Linux watchdog timer
interface on top of the IPMI message handler.
ipmi_poweroff - Some systems support the ability to be turned off via
IPMI commands.
bt-bmc - This is not part of the main driver, but instead a driver for
accessing a BMC-side interface of a BT interface. It is used on BMCs
running Linux to provide an interface to the host.
These are all individually selectable via configuration options.
Much documentation for the interface is in the include files. The
IPMI include files are:
linux/ipmi.h - Contains the user interface and IOCTL interface for IPMI.
linux/ipmi_smi.h - Contains the interface for system management interfaces
(things that interface to IPMI controllers) to use.
linux/ipmi_msgdefs.h - General definitions for base IPMI messaging.
Addressing
----------
The IPMI addressing works much like IP addresses, you have an overlay
to handle the different address types. The overlay is::
struct ipmi_addr
{
int addr_type;
short channel;
char data[IPMI_MAX_ADDR_SIZE];
};
The addr_type determines what the address really is. The driver
currently understands two different types of addresses.
"System Interface" addresses are defined as::
struct ipmi_system_interface_addr
{
int addr_type;
short channel;
};
and the type is IPMI_SYSTEM_INTERFACE_ADDR_TYPE. This is used for talking
straight to the BMC on the current card. The channel must be
IPMI_BMC_CHANNEL.
Messages that are destined to go out on the IPMB bus going through the
BMC use the IPMI_IPMB_ADDR_TYPE address type. The format is::
struct ipmi_ipmb_addr
{
int addr_type;
short channel;
unsigned char slave_addr;
unsigned char lun;
};
The "channel" here is generally zero, but some devices support more
than one channel, it corresponds to the channel as defined in the IPMI
spec.
There is also an IPMB direct address for a situation where the sender
is directly on an IPMB bus and doesn't have to go through the BMC.
You can send messages to a specific management controller (MC) on the
IPMB using the IPMI_IPMB_DIRECT_ADDR_TYPE with the following format::
struct ipmi_ipmb_direct_addr
{
int addr_type;
short channel;
unsigned char slave_addr;
unsigned char rq_lun;
unsigned char rs_lun;
};
The channel is always zero. You can also receive commands from other
MCs that you have registered to handle and respond to them, so you can
use this to implement a management controller on a bus..
Messages
--------
Messages are defined as::
struct ipmi_msg
{
unsigned char netfn;
unsigned char lun;
unsigned char cmd;
unsigned char *data;
int data_len;
};
The driver takes care of adding/stripping the header information. The
data portion is just the data to be send (do NOT put addressing info
here) or the response. Note that the completion code of a response is
the first item in "data", it is not stripped out because that is how
all the messages are defined in the spec (and thus makes counting the
offsets a little easier :-).
When using the IOCTL interface from userland, you must provide a block
of data for "data", fill it, and set data_len to the length of the
block of data, even when receiving messages. Otherwise the driver
will have no place to put the message.
Messages coming up from the message handler in kernelland will come in
as::
struct ipmi_recv_msg
{
struct list_head link;
/* The type of message as defined in the "Receive Types"
defines above. */
int recv_type;
ipmi_user_t *user;
struct ipmi_addr addr;
long msgid;
struct ipmi_msg msg;
/* Call this when done with the message. It will presumably free
the message and do any other necessary cleanup. */
void (*done)(struct ipmi_recv_msg *msg);
/* Place-holder for the data, don't make any assumptions about
the size or existence of this, since it may change. */
unsigned char msg_data[IPMI_MAX_MSG_LENGTH];
};
You should look at the receive type and handle the message
appropriately.
The Upper Layer Interface (Message Handler)
-------------------------------------------
The upper layer of the interface provides the users with a consistent
view of the IPMI interfaces. It allows multiple SMI interfaces to be
addressed (because some boards actually have multiple BMCs on them)
and the user should not have to care what type of SMI is below them.
Watching For Interfaces
^^^^^^^^^^^^^^^^^^^^^^^
When your code comes up, the IPMI driver may or may not have detected
if IPMI devices exist. So you might have to defer your setup until
the device is detected, or you might be able to do it immediately.
To handle this, and to allow for discovery, you register an SMI
watcher with ipmi_smi_watcher_register() to iterate over interfaces
and tell you when they come and go.
Creating the User
^^^^^^^^^^^^^^^^^
To use the message handler, you must first create a user using
ipmi_create_user. The interface number specifies which SMI you want
to connect to, and you must supply callback functions to be called
when data comes in. This also allows to you pass in a piece of data,
the handler_data, that will be passed back to you on all calls.
Once you are done, call ipmi_destroy_user() to get rid of the user.
From userland, opening the device automatically creates a user, and
closing the device automatically destroys the user.
Messaging
^^^^^^^^^
To send a message from kernel-land, the ipmi_request_settime() call does
pretty much all message handling. Most of the parameter are
self-explanatory. However, it takes a "msgid" parameter. This is NOT
the sequence number of messages. It is simply a long value that is
passed back when the response for the message is returned. You may
use it for anything you like.
Responses come back in the function pointed to by the ipmi_recv_hndl
field of the "handler" that you passed in to ipmi_create_user().
Remember to look at the receive type, too.
From userland, you fill out an ipmi_req_t structure and use the
IPMICTL_SEND_COMMAND ioctl. For incoming stuff, you can use select()
or poll() to wait for messages to come in. However, you cannot use
read() to get them, you must call the IPMICTL_RECEIVE_MSG with the
ipmi_recv_t structure to actually get the message. Remember that you
must supply a pointer to a block of data in the msg.data field, and
you must fill in the msg.data_len field with the size of the data.
This gives the receiver a place to actually put the message.
If the message cannot fit into the data you provide, you will get an
EMSGSIZE error and the driver will leave the data in the receive
queue. If you want to get it and have it truncate the message, use
the IPMICTL_RECEIVE_MSG_TRUNC ioctl.
When you send a command (which is defined by the lowest-order bit of
the netfn per the IPMI spec) on the IPMB bus, the driver will
automatically assign the sequence number to the command and save the
command. If the response is not received in the IPMI-specified 5
seconds, it will generate a response automatically saying the command
timed out. If an unsolicited response comes in (if it was after 5
seconds, for instance), that response will be ignored.
In kernelland, after you receive a message and are done with it, you
MUST call ipmi_free_recv_msg() on it, or you will leak messages. Note
that you should NEVER mess with the "done" field of a message, that is
required to properly clean up the message.
Note that when sending, there is an ipmi_request_supply_msgs() call
that lets you supply the smi and receive message. This is useful for
pieces of code that need to work even if the system is out of buffers
(the watchdog timer uses this, for instance). You supply your own
buffer and own free routines. This is not recommended for normal use,
though, since it is tricky to manage your own buffers.
Events and Incoming Commands
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The driver takes care of polling for IPMI events and receiving
commands (commands are messages that are not responses, they are
commands that other things on the IPMB bus have sent you). To receive
these, you must register for them, they will not automatically be sent
to you.
To receive events, you must call ipmi_set_gets_events() and set the
"val" to non-zero. Any events that have been received by the driver
since startup will immediately be delivered to the first user that
registers for events. After that, if multiple users are registered
for events, they will all receive all events that come in.
For receiving commands, you have to individually register commands you
want to receive. Call ipmi_register_for_cmd() and supply the netfn
and command name for each command you want to receive. You also
specify a bitmask of the channels you want to receive the command from
(or use IPMI_CHAN_ALL for all channels if you don't care). Only one
user may be registered for each netfn/cmd/channel, but different users
may register for different commands, or the same command if the
channel bitmasks do not overlap.
To respond to a received command, set the response bit in the returned
netfn, use the address from the received message, and use the same
msgid that you got in the received message.
From userland, equivalent IOCTLs are provided to do these functions.
The Lower Layer (SMI) Interface
-------------------------------
As mentioned before, multiple SMI interfaces may be registered to the
message handler, each of these is assigned an interface number when
they register with the message handler. They are generally assigned
in the order they register, although if an SMI unregisters and then
another one registers, all bets are off.
The ipmi_smi.h defines the interface for management interfaces, see
that for more details.
The SI Driver
-------------
The SI driver allows KCS, BT, and SMIC interfaces to be configured
in the system. It discovers interfaces through a host of different
methods, depending on the system.
You can specify up to four interfaces on the module load line and
control some module parameters::
modprobe ipmi_si.o type=<type1>,<type2>....
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
irqs=<irq1>,<irq2>...
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
regshifts=<shift1>,<shift2>,...
slave_addrs=<addr1>,<addr2>,...
force_kipmid=<enable1>,<enable2>,...
kipmid_max_busy_us=<ustime1>,<ustime2>,...
unload_when_empty=[0|1]
trydmi=[0|1] tryacpi=[0|1]
tryplatform=[0|1] trypci=[0|1]
Each of these except try... items is a list, the first item for the
first interface, second item for the second interface, etc.
The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it
defaults to "kcs".
If you specify addrs as non-zero for an interface, the driver will
use the memory address given as the address of the device. This
overrides si_ports.
If you specify ports as non-zero for an interface, the driver will
use the I/O port given as the device address.
If you specify irqs as non-zero for an interface, the driver will
attempt to use the given interrupt for the device.
The other try... items disable discovery by their corresponding
names. These are all enabled by default, set them to zero to disable
them. The tryplatform disables openfirmware.
The next three parameters have to do with register layout. The
registers used by the interfaces may not appear at successive
locations and they may not be in 8-bit registers. These parameters
allow the layout of the data in the registers to be more precisely
specified.
The regspacings parameter give the number of bytes between successive
register start addresses. For instance, if the regspacing is set to 4
and the start address is 0xca2, then the address for the second
register would be 0xca6. This defaults to 1.
The regsizes parameter gives the size of a register, in bytes. The
data used by IPMI is 8-bits wide, but it may be inside a larger
register. This parameter allows the read and write type to be specified.
It may be 1, 2, 4, or 8. The default is 1.
Since the register size may be larger than 32 bits, the IPMI data may not
be in the lower 8 bits. The regshifts parameter give the amount to shift
the data to get to the actual IPMI data.
The slave_addrs specifies the IPMI address of the local BMC. This is
usually 0x20 and the driver defaults to that, but in case it's not, it
can be specified when the driver starts up.
The force_ipmid parameter forcefully enables (if set to 1) or disables
(if set to 0) the kernel IPMI daemon. Normally this is auto-detected
by the driver, but systems with broken interrupts might need an enable,
or users that don't want the daemon (don't need the performance, don't
want the CPU hit) can disable it.
If unload_when_empty is set to 1, the driver will be unloaded if it
doesn't find any interfaces or all the interfaces fail to work. The
default is one. Setting to 0 is useful with the hotmod, but is
obviously only useful for modules.
When compiled into the kernel, the parameters can be specified on the
kernel command line as::
ipmi_si.type=<type1>,<type2>...
ipmi_si.ports=<port1>,<port2>... ipmi_si.addrs=<addr1>,<addr2>...
ipmi_si.irqs=<irq1>,<irq2>...
ipmi_si.regspacings=<sp1>,<sp2>,...
ipmi_si.regsizes=<size1>,<size2>,...
ipmi_si.regshifts=<shift1>,<shift2>,...
ipmi_si.slave_addrs=<addr1>,<addr2>,...
ipmi_si.force_kipmid=<enable1>,<enable2>,...
ipmi_si.kipmid_max_busy_us=<ustime1>,<ustime2>,...
It works the same as the module parameters of the same names.
If your IPMI interface does not support interrupts and is a KCS or
SMIC interface, the IPMI driver will start a kernel thread for the
interface to help speed things up. This is a low-priority kernel
thread that constantly polls the IPMI driver while an IPMI operation
is in progress. The force_kipmid module parameter will allow the user
to force this thread on or off. If you force it off and don't have
interrupts, the driver will run VERY slowly. Don't blame me,
these interfaces suck.
Unfortunately, this thread can use a lot of CPU depending on the
interface's performance. This can waste a lot of CPU and cause
various issues with detecting idle CPU and using extra power. To
avoid this, the kipmid_max_busy_us sets the maximum amount of time, in
microseconds, that kipmid will spin before sleeping for a tick. This
value sets a balance between performance and CPU waste and needs to be
tuned to your needs. Maybe, someday, auto-tuning will be added, but
that's not a simple thing and even the auto-tuning would need to be
tuned to the user's desired performance.
The driver supports a hot add and remove of interfaces. This way,
interfaces can be added or removed after the kernel is up and running.
This is done using /sys/modules/ipmi_si/parameters/hotmod, which is a
write-only parameter. You write a string to this interface. The string
has the format::
<op1>[:op2[:op3...]]
The "op"s are::
add|remove,kcs|bt|smic,mem|i/o,<address>[,<opt1>[,<opt2>[,...]]]
You can specify more than one interface on the line. The "opt"s are::
rsp=<regspacing>
rsi=<regsize>
rsh=<regshift>
irq=<irq>
ipmb=<ipmb slave addr>
and these have the same meanings as discussed above. Note that you
can also use this on the kernel command line for a more compact format
for specifying an interface. Note that when removing an interface,
only the first three parameters (si type, address type, and address)
are used for the comparison. Any options are ignored for removing.
The SMBus Driver (SSIF)
-----------------------
The SMBus driver allows up to 4 SMBus devices to be configured in the
system. By default, the driver will only register with something it
finds in DMI or ACPI tables. You can change this
at module load time (for a module) with::
modprobe ipmi_ssif.o
addr=<i2caddr1>[,<i2caddr2>[,...]]
adapter=<adapter1>[,<adapter2>[...]]
dbg=<flags1>,<flags2>...
slave_addrs=<addr1>,<addr2>,...
tryacpi=[0|1] trydmi=[0|1]
[dbg_probe=1]
alerts_broken
The addresses are normal I2C addresses. The adapter is the string
name of the adapter, as shown in /sys/bus/i2c/devices/i2c-<n>/name.
It is *NOT* i2c-<n> itself. Also, the comparison is done ignoring
spaces, so if the name is "This is an I2C chip" you can say
adapter_name=ThisisanI2cchip. This is because it's hard to pass in
spaces in kernel parameters.
The debug flags are bit flags for each BMC found, they are:
IPMI messages: 1, driver state: 2, timing: 4, I2C probe: 8
The tryxxx parameters can be used to disable detecting interfaces
from various sources.
Setting dbg_probe to 1 will enable debugging of the probing and
detection process for BMCs on the SMBusses.
The slave_addrs specifies the IPMI address of the local BMC. This is
usually 0x20 and the driver defaults to that, but in case it's not, it
can be specified when the driver starts up.
alerts_broken does not enable SMBus alert for SSIF. Otherwise SMBus
alert will be enabled on supported hardware.
Discovering the IPMI compliant BMC on the SMBus can cause devices on
the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI
message as a block write to the I2C bus and waits for a response.
This action can be detrimental to some I2C devices. It is highly
recommended that the known I2C address be given to the SMBus driver in
the smb_addr parameter unless you have DMI or ACPI data to tell the
driver what to use.
When compiled into the kernel, the addresses can be specified on the
kernel command line as::
ipmb_ssif.addr=<i2caddr1>[,<i2caddr2>[...]]
ipmi_ssif.adapter=<adapter1>[,<adapter2>[...]]
ipmi_ssif.dbg=<flags1>[,<flags2>[...]]
ipmi_ssif.dbg_probe=1
ipmi_ssif.slave_addrs=<addr1>[,<addr2>[...]]
ipmi_ssif.tryacpi=[0|1] ipmi_ssif.trydmi=[0|1]
These are the same options as on the module command line.
The I2C driver does not support non-blocking access or polling, so
this driver cannot do IPMI panic events, extend the watchdog at panic
time, or other panic-related IPMI functions without special kernel
patches and driver modifications. You can get those at the openipmi
web page.
The driver supports a hot add and remove of interfaces through the I2C
sysfs interface.
The IPMI IPMB Driver
--------------------
This driver is for supporting a system that sits on an IPMB bus; it
allows the interface to look like a normal IPMI interface. Sending
system interface addressed messages to it will cause the message to go
to the registered BMC on the system (default at IPMI address 0x20).
It also allows you to directly address other MCs on the bus using the
ipmb direct addressing. You can receive commands from other MCs on
the bus and they will be handled through the normal received command
mechanism described above.
Parameters are::
ipmi_ipmb.bmcaddr=<address to use for system interface addresses messages>
ipmi_ipmb.retry_time_ms=<Time between retries on IPMB>
ipmi_ipmb.max_retries=<Number of times to retry a message>
Loading the module will not result in the driver automatically
starting unless there is device tree information setting it up. If
you want to instantiate one of these by hand, do::
echo ipmi-ipmb <addr> > /sys/class/i2c-dev/i2c-<n>/device/new_device
Note that the address you give here is the I2C address, not the IPMI
address. So if you want your MC address to be 0x60, you put 0x30
here. See the I2C driver info for more details.
Command bridging to other IPMB buses through this interface does not
work. The receive message queue is not implemented, by design. There
is only one receive message queue on a BMC, and that is meant for the
host drivers, not something on the IPMB bus.
A BMC may have multiple IPMB buses, which bus your device sits on
depends on how the system is wired. You can fetch the channels with
"ipmitool channel info <n>" where <n> is the channel, with the
channels being 0-7 and try the IPMB channels.
Other Pieces
------------
Get the detailed info related with the IPMI device
--------------------------------------------------
Some users need more detailed information about a device, like where
the address came from or the raw base device for the IPMI interface.
You can use the IPMI smi_watcher to catch the IPMI interfaces as they
come or go, and to grab the information, you can use the function
ipmi_get_smi_info(), which returns the following structure::
struct ipmi_smi_info {
enum ipmi_addr_src addr_src;
struct device *dev;
union {
struct {
void *acpi_handle;
} acpi_info;
} addr_info;
};
Currently special info for only for SI_ACPI address sources is
returned. Others may be added as necessary.
Note that the dev pointer is included in the above structure, and
assuming ipmi_smi_get_info returns success, you must call put_device
on the dev pointer.
Watchdog
--------
A watchdog timer is provided that implements the Linux-standard
watchdog timer interface. It has three module parameters that can be
used to control it::
modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
preaction=<preaction type> preop=<preop type> start_now=x
nowayout=x ifnum_to_use=n panic_wdt_timeout=<t>
ifnum_to_use specifies which interface the watchdog timer should use.
The default is -1, which means to pick the first one registered.
The timeout is the number of seconds to the action, and the pretimeout
is the amount of seconds before the reset that the pre-timeout panic will
occur (if pretimeout is zero, then pretimeout will not be enabled). Note
that the pretimeout is the time before the final timeout. So if the
timeout is 50 seconds and the pretimeout is 10 seconds, then the pretimeout
will occur in 40 second (10 seconds before the timeout). The panic_wdt_timeout
is the value of timeout which is set on kernel panic, in order to let actions
such as kdump to occur during panic.
The action may be "reset", "power_cycle", or "power_off", and
specifies what to do when the timer times out, and defaults to
"reset".
The preaction may be "pre_smi" for an indication through the SMI
interface, "pre_int" for an indication through the SMI with an
interrupts, and "pre_nmi" for a NMI on a preaction. This is how
the driver is informed of the pretimeout.
The preop may be set to "preop_none" for no operation on a pretimeout,
"preop_panic" to set the preoperation to panic, or "preop_give_data"
to provide data to read from the watchdog device when the pretimeout
occurs. A "pre_nmi" setting CANNOT be used with "preop_give_data"
because you can't do data operations from an NMI.
When preop is set to "preop_give_data", one byte comes ready to read
on the device when the pretimeout occurs. Select and fasync work on
the device, as well.
If start_now is set to 1, the watchdog timer will start running as
soon as the driver is loaded.
If nowayout is set to 1, the watchdog timer will not stop when the
watchdog device is closed. The default value of nowayout is true
if the CONFIG_WATCHDOG_NOWAYOUT option is enabled, or false if not.
When compiled into the kernel, the kernel command line is available
for configuring the watchdog::
ipmi_watchdog.timeout=<t> ipmi_watchdog.pretimeout=<t>
ipmi_watchdog.action=<action type>
ipmi_watchdog.preaction=<preaction type>
ipmi_watchdog.preop=<preop type>
ipmi_watchdog.start_now=x
ipmi_watchdog.nowayout=x
ipmi_watchdog.panic_wdt_timeout=<t>
The options are the same as the module parameter options.
The watchdog will panic and start a 120 second reset timeout if it
gets a pre-action. During a panic or a reboot, the watchdog will
start a 120 timer if it is running to make sure the reboot occurs.
Note that if you use the NMI preaction for the watchdog, you MUST NOT
use the nmi watchdog. There is no reasonable way to tell if an NMI
comes from the IPMI controller, so it must assume that if it gets an
otherwise unhandled NMI, it must be from IPMI and it will panic
immediately.
Once you open the watchdog timer, you must write a 'V' character to the
device to close it, or the timer will not stop. This is a new semantic
for the driver, but makes it consistent with the rest of the watchdog
drivers in Linux.
Panic Timeouts
--------------
The OpenIPMI driver supports the ability to put semi-custom and custom
events in the system event log if a panic occurs. if you enable the
'Generate a panic event to all BMCs on a panic' option, you will get
one event on a panic in a standard IPMI event format. If you enable
the 'Generate OEM events containing the panic string' option, you will
also get a bunch of OEM events holding the panic string.
The field settings of the events are:
* Generator ID: 0x21 (kernel)
* EvM Rev: 0x03 (this event is formatting in IPMI 1.0 format)
* Sensor Type: 0x20 (OS critical stop sensor)
* Sensor #: The first byte of the panic string (0 if no panic string)
* Event Dir | Event Type: 0x6f (Assertion, sensor-specific event info)
* Event Data 1: 0xa1 (Runtime stop in OEM bytes 2 and 3)
* Event data 2: second byte of panic string
* Event data 3: third byte of panic string
See the IPMI spec for the details of the event layout. This event is
always sent to the local management controller. It will handle routing
the message to the right place
Other OEM events have the following format:
* Record ID (bytes 0-1): Set by the SEL.
* Record type (byte 2): 0xf0 (OEM non-timestamped)
* byte 3: The slave address of the card saving the panic
* byte 4: A sequence number (starting at zero)
The rest of the bytes (11 bytes) are the panic string. If the panic string
is longer than 11 bytes, multiple messages will be sent with increasing
sequence numbers.
Because you cannot send OEM events using the standard interface, this
function will attempt to find an SEL and add the events there. It
will first query the capabilities of the local management controller.
If it has an SEL, then they will be stored in the SEL of the local
management controller. If not, and the local management controller is
an event generator, the event receiver from the local management
controller will be queried and the events sent to the SEL on that
device. Otherwise, the events go nowhere since there is nowhere to
send them.
Poweroff
--------
If the poweroff capability is selected, the IPMI driver will install
a shutdown function into the standard poweroff function pointer. This
is in the ipmi_poweroff module. When the system requests a powerdown,
it will send the proper IPMI commands to do this. This is supported on
several platforms.
There is a module parameter named "poweroff_powercycle" that may
either be zero (do a power down) or non-zero (do a power cycle, power
the system off, then power it on in a few seconds). Setting
ipmi_poweroff.poweroff_control=x will do the same thing on the kernel
command line. The parameter is also available via the proc filesystem
in /proc/sys/dev/ipmi/poweroff_powercycle. Note that if the system
does not support power cycling, it will always do the power off.
The "ifnum_to_use" parameter specifies which interface the poweroff
code should use. The default is -1, which means to pick the first one
registered.
Note that if you have ACPI enabled, the system will prefer using ACPI to
power off.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Linux IPMI driver 개요
1-23문서 제목은 `The Linux IPMI Driver`이며 저자는 Corey Minyard입니다. IPMI(Intelligent Platform Management Interface)는 system을 감시하는 intelligent device를 제어하기 위한 표준입니다.
IPMI는 system sensor를 dynamic discovery하고 값을 monitor하며 값이 변하거나 정해진 boundary를 벗어날 때 통지하는 기능을 제공합니다. 또한 FRU(field-replaceable unit)를 위한 표준 database와 watchdog timer를 정의합니다.
이 기능을 사용하려면 system 안의 IPMI controller인 BMC(Baseboard Management Controller)에 접근할 interface와 IPMI system을 사용할 management software가 필요합니다. 이 문서는 Linux IPMI driver 사용법을 설명하며 IPMI 자체의 전체 specification은 원문에 연결된 Intel IPMI site를 참고해야 합니다.
Management software가 Linux driver를 거쳐 BMC와 sensor에 접근합니다.
Configuration
24-87Linux IPMI driver는 modular하므로 hardware와 필요 기능에 맞춰 여러 항목을 선택해야 합니다. 대부분의 option은 `Character Devices` 아래 IPMI menu에 있습니다. IPMI를 사용하려면 항상 `IPMI top-level message handler`를 선택해야 하며, 그 밖의 항목은 목적과 hardware에 따라 결정합니다.
Message handler 자체는 user-level interface를 제공하지 않지만 watchdog 같은 kernel code는 사용할 수 있습니다. Userland에서 device driver를 통해 접근하려면 `Device interface for IPMI`를 선택합니다.
Physical interface 선택은 hardware에 달려 있습니다. SMBIOS가 올바른 IPMI 정보를 제공하면 driver가 자동 감지합니다. 표준 KCS, SMIC, BT interface에는 `IPMI SI handler`를 사용합니다. BMC에 직접 I2C로 접근하는 board에는 `IPMI SMBus handler`를 사용할 수 있지만 SMBIOS/ACPI 정보가 없거나 잘못되면 수동 확인이 필요합니다. SI와 SMBus handler를 함께 enable하고 auto-detection에 맡겨도 대체로 안전합니다.
IPMI system은 ACPI table로 description될 수 있으므로 일반적으로 ACPI를 enable해야 합니다. 제조사가 ACPI 또는 SMBIOS table을 올바르게 제공했다면 controller가 자동 검출되지만, 정보가 없는 board에서는 standard default가 실패할 수 있으므로 아래 `The SI Driver` 또는 `The SMBus Driver` 절의 수동 설정을 사용합니다.
`IPMI Watchdog Timer` option은 IPMI 표준 watchdog을 enable합니다. Driver를 kernel에 built-in하면 command-line option으로 initialization 직후 timer를 시작할 수 있습니다. 기본적으로 device close 때 watchdog을 disable하지만 `Watchdog Timer Support`와 `Disable watchdog shutdown on close`를 enable하면 close 뒤에도 계속 실행할 수 있습니다.
`IPMI Poweroff`는 standard chassis management command 등을 지원하는 system을 IPMI로 끕니다. Driver가 capability를 auto-detect하므로 미지원 system에서도 option을 enable하는 것은 안전합니다. ATCA system, Radisys CPI1 card와 standard chassis command를 지원하는 IPMI system에서 동작합니다.
Panic 때 모든 BMC의 event log에 event를 남기려면 `Generate a panic event to all BMCs on a panic`을, panic string 전체를 OEM event로 남기려면 `Generate OEM events containing the panic string`을 enable합니다. Runtime에는 `ipmi_msghandler`의 `panic_op` module parameter를 `event`, `string`, `none`으로 설정해 각각 standard event, OEM string event, disable을 선택합니다.
기능과 필요한 kernel option을 대응시켰습니다.
Firmware 정보가 없을 때 수동 SI·SMBus 설정으로 전환합니다.
Basic Design
88-140Linux IPMI driver는 필요한 component만 선택하도록 여러 module로 분리되어 있습니다. `ipmi_msghandler`는 message, timing, response를 모두 처리하는 중심 component입니다. IPMI user와 physical SMI(System Management Interface)가 여기에 연결되며 kernel interface를 제공하지만 application process용 interface는 직접 제공하지 않습니다.
`ipmi_devintf`는 userland ioctl interface를 제공하고, 이 device의 open file 하나마다 message handler에 IPMI user 하나로 연결됩니다. `ipmi_si`는 KCS, SMIC, BT system interface driver입니다. SMBus 또는 custom interface가 아니라면 일반적으로 이 module이 필요합니다.
`ipmi_ssif`는 I2C kernel driver의 SMBus interface를 이용해 SMBus 위로 IPMI message를 송수신합니다. `ipmi_powernv`는 POWERNV system에서 BMC access를 제공합니다.
`ipmi_watchdog`는 IPMI의 강력한 watchdog timer를 standard Linux watchdog interface로 노출합니다. `ipmi_poweroff`는 IPMI command로 system을 끌 수 있는 platform을 지원합니다. `bt-bmc`는 main driver 일부가 아니라 Linux를 실행하는 BMC에서 BT interface의 BMC-side를 host에 제공하는 별도 driver입니다.
각 component는 configuration option으로 개별 선택할 수 있습니다. Interface 상세는 include file에도 있습니다. `linux/ipmi.h`는 user·ioctl interface, `linux/ipmi_smi.h`는 IPMI controller에 연결하는 system management interface, `linux/ipmi_msgdefs.h`는 base IPMI messaging의 일반 definition을 담습니다.
Upper-layer user와 physical interface가 message handler를 중심으로 결합됩니다.
Module별 책임을 정리했습니다.
Addressing
141-201IPMI addressing은 IP address와 비슷하게 공통 overlay가 여러 address type을 표현합니다. `struct ipmi_addr`의 `addr_type`이 실제 address layout을 결정하고 `channel`과 최대 크기의 `data`가 뒤따릅니다.
struct ipmi_addr
{
int addr_type;
short channel;
char data[IPMI_MAX_ADDR_SIZE];
};System interface address는 `struct ipmi_system_interface_addr`이며 type은 `IPMI_SYSTEM_INTERFACE_ADDR_TYPE`입니다. 현재 card의 BMC와 직접 통신할 때 사용하고 channel은 반드시 `IPMI_BMC_CHANNEL`이어야 합니다.
struct ipmi_system_interface_addr
{
int addr_type;
short channel;
};BMC를 거쳐 IPMB bus로 나가는 message에는 `IPMI_IPMB_ADDR_TYPE`과 `struct ipmi_ipmb_addr`를 사용합니다. `channel`은 일반적으로 0이지만 여러 channel을 지원하는 device에서는 IPMI specification의 channel 번호에 대응합니다.
struct ipmi_ipmb_addr
{
int addr_type;
short channel;
unsigned char slave_addr;
unsigned char lun;
};Sender가 IPMB bus에 직접 연결되어 BMC를 거치지 않는 경우에는 `IPMI_IPMB_DIRECT_ADDR_TYPE`과 `struct ipmi_ipmb_direct_addr`를 사용합니다. `channel`은 항상 0입니다. 등록한 command를 다른 MC에서 받아 응답할 수도 있으므로 이 address type으로 bus 위 management controller를 구현할 수 있습니다.
struct ipmi_ipmb_direct_addr
{
int addr_type;
short channel;
unsigned char slave_addr;
unsigned char rq_lun;
unsigned char rs_lun;
};Destination과 route에 따른 address layout입니다.
System interface와 두 IPMB route의 차이입니다.
Messages
202-256IPMI message는 `struct ipmi_msg`로 표현합니다. Driver가 address header를 추가하고 제거하므로 `data`에는 addressing 정보가 아니라 보낼 payload 또는 response만 넣습니다. Response completion code는 specification의 message layout대로 `data`의 첫 byte에 남아 있으며 driver가 제거하지 않습니다.
struct ipmi_msg
{
unsigned char netfn;
unsigned char lun;
unsigned char cmd;
unsigned char *data;
int data_len;
};Userland ioctl interface를 사용할 때는 message 수신 시에도 `data`용 buffer를 할당해 pointer를 제공하고 `data_len`에 buffer 크기를 넣어야 합니다. 그렇지 않으면 driver가 message를 저장할 곳이 없습니다.
Kernel message handler가 upper layer로 전달하는 message는 `struct ipmi_recv_msg`입니다. `recv_type`을 확인해 message 종류에 맞게 처리해야 합니다. `done` callback은 사용이 끝난 message를 free하고 필요한 cleanup을 수행하며, `msg_data`는 내부 placeholder이므로 size나 존재 여부에 의존하면 안 됩니다.
struct ipmi_recv_msg
{
struct list_head link;
/* The type of message as defined in the "Receive Types"
defines above. */
int recv_type;
ipmi_user_t *user;
struct ipmi_addr addr;
long msgid;
struct ipmi_msg msg;
/* Call this when done with the message. It will presumably free
the message and do any other necessary cleanup. */
void (*done)(struct ipmi_recv_msg *msg);
/* Place-holder for the data, don't make any assumptions about
the size or existence of this, since it may change. */
unsigned char msg_data[IPMI_MAX_MSG_LENGTH];
};Driver가 header를 관리하고 caller는 payload buffer를 소유합니다.
수신자가 지켜야 할 ownership 규칙입니다.
Upper layer와 interface 감시
257-276Upper layer message handler는 user에게 모든 IPMI interface의 일관된 view를 제공합니다. 일부 board는 BMC가 여러 개이므로 여러 SMI interface를 address할 수 있고, user는 아래 physical SMI type을 알 필요가 없습니다.
Code가 시작될 때 IPMI device detection이 끝났을 수도 있고 아직 아닐 수도 있습니다. 즉시 setup하거나 detection까지 미뤄야 하는 두 경우를 모두 처리하려면 `ipmi_smi_watcher_register()`로 SMI watcher를 등록합니다. Watcher는 existing interface를 순회하고 interface가 추가되거나 제거될 때 알려 줍니다.
초기 discovery와 runtime add/remove를 같은 callback model로 처리합니다.
IPMI user 생성과 제거
277-291Message handler를 사용하려면 먼저 `ipmi_create_user()`로 user를 생성합니다. Interface number로 연결할 SMI를 고르고 incoming data callback을 제공합니다. `handler_data`에는 모든 callback에서 되돌려 받을 caller data를 넣을 수 있습니다.
사용이 끝나면 `ipmi_destroy_user()`를 호출합니다. Userland에서는 device open이 user를 자동 생성하고 close가 자동 제거합니다.
Kernel API와 userland device lifecycle을 대응시켰습니다.
Messaging API
292-340Kernel에서 message를 보낼 때 `ipmi_request_settime()`이 대부분의 message 처리를 수행합니다. `msgid`는 sequence number가 아니라 response가 돌아올 때 그대로 반환되는 `long` 값이므로 caller가 원하는 correlation 용도로 사용할 수 있습니다. Response는 `ipmi_create_user()`에 넘긴 handler의 `ipmi_recv_hndl` callback으로 전달되며 `recv_type`도 확인해야 합니다.
Userland에서는 `ipmi_req_t`를 채워 `IPMICTL_SEND_COMMAND` ioctl로 보냅니다. Incoming message는 `select()` 또는 `poll()`로 기다릴 수 있지만 `read()`로 받을 수는 없습니다. 실제 수신은 `ipmi_recv_t`와 `IPMICTL_RECEIVE_MSG` ioctl을 사용하며 `msg.data`에 buffer pointer, `msg.data_len`에 buffer 크기를 반드시 제공합니다.
Message가 caller buffer에 들어가지 않으면 `EMSGSIZE`를 반환하고 receive queue에 그대로 둡니다. Truncation을 허용해 가져오려면 `IPMICTL_RECEIVE_MSG_TRUNC` ioctl을 사용합니다.
IPMI specification에서 netfn의 lowest-order bit로 구분되는 command를 IPMB로 보내면 driver가 sequence number를 자동 할당하고 command를 보관합니다. Specification의 5초 안에 response가 없으면 timeout response를 자동 생성하고, 5초 이후와 같은 unsolicited response는 무시합니다.
Kernel에서 received message 처리가 끝나면 반드시 `ipmi_free_recv_msg()`를 호출해야 합니다. 그렇지 않으면 message가 leak됩니다. Proper cleanup에 필요한 `done` field는 절대 변경하면 안 됩니다.
`ipmi_request_supply_msgs()`는 caller가 SMI message와 receive message buffer 및 free routine을 직접 제공하게 합니다. Watchdog처럼 system buffer가 고갈되어도 동작해야 하는 code에 유용하지만 buffer 관리가 까다로우므로 normal use에는 권장하지 않습니다.
ioctl 기반 message path와 buffer requirement입니다.
Kernel caller가 지켜야 할 수명 규칙입니다.
Event와 incoming command
341-371Driver는 IPMI event polling과 incoming command 수신을 처리합니다. 여기서 command는 response가 아니라 IPMB bus의 다른 component가 보낸 request입니다. Event와 command는 자동 전달되지 않으므로 user가 등록해야 합니다.
Event를 받으려면 `ipmi_set_gets_events()`의 `val`을 0이 아닌 값으로 설정합니다. Driver start 이후 쌓인 event는 event를 처음 등록한 user에게 즉시 전달됩니다. 그 뒤 여러 user가 등록되어 있으면 새 event를 모두에게 전달합니다.
Command는 받을 `netfn`과 command마다 `ipmi_register_for_cmd()`를 호출합니다. Channel bitmask를 지정하거나 모든 channel에는 `IPMI_CHAN_ALL`을 사용합니다. 동일한 `netfn/cmd/channel`에는 user 하나만 등록할 수 있지만 command가 다르거나 channel bitmask가 겹치지 않으면 서로 다른 user가 등록할 수 있습니다.
Received command에 응답하려면 반환된 netfn에 response bit를 설정하고, received message의 address와 같은 `msgid`를 사용합니다. Userland에도 이 기능에 대응하는 ioctl이 제공됩니다.
Startup backlog와 이후 fan-out 동작입니다.
Registration key와 response identity 규칙입니다.
Lower layer SMI interface
372-384여러 SMI interface가 message handler에 등록될 수 있으며 등록 시 각 interface number를 받습니다. 일반적으로 등록 순서대로 번호가 정해지지만 SMI가 unregister된 뒤 다른 SMI가 등록되면 번호 순서를 가정할 수 없습니다.
Management interface가 구현해야 할 lower-layer contract의 상세는 `linux/ipmi_smi.h`에 정의되어 있습니다.
Runtime 등록 상태에 따라 interface number가 부여됩니다.
SI driver 설정
385-461SI driver는 KCS, BT, SMIC interface를 구성하며 system 종류에 따라 여러 discovery method를 사용합니다. Module load line에서 interface를 최대 4개 지정하고 각 parameter list의 첫 항목은 첫 interface, 둘째 항목은 둘째 interface에 대응합니다.
modprobe ipmi_si.o type=<type1>,<type2>....
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
irqs=<irq1>,<irq2>...
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
regshifts=<shift1>,<shift2>,...
slave_addrs=<addr1>,<addr2>,...
force_kipmid=<enable1>,<enable2>,...
kipmid_max_busy_us=<ustime1>,<ustime2>,...
unload_when_empty=[0|1]
trydmi=[0|1] tryacpi=[0|1]
tryplatform=[0|1] trypci=[0|1]`type`은 `kcs`, `smic`, `bt` 중 하나이며 생략하면 `kcs`입니다. Interface의 `addrs`가 0이 아니면 memory address를 device address로 사용하고 `ports`보다 우선합니다. `ports`가 0이 아니면 지정 I/O port를 사용하며, `irqs`가 0이 아니면 해당 interrupt 사용을 시도합니다.
`trydmi`, `tryacpi`, `tryplatform`, `trypci`는 이름에 대응하는 discovery source를 제어합니다. 기본적으로 모두 enable이며 0으로 disable합니다. `tryplatform`은 OpenFirmware도 disable합니다.
Register가 연속 address에 있지 않거나 8-bit register가 아닐 수 있으므로 `regspacings`, `regsizes`, `regshifts`로 layout을 지정합니다. `regspacings`는 연속 register start 사이 byte 수이며 기본값은 1입니다. 예를 들어 start `0xca2`, spacing 4이면 둘째 register는 `0xca6`입니다.
`regsizes`는 register byte 크기로 1, 2, 4, 8 중 하나이며 기본값은 1입니다. IPMI data는 8-bit지만 더 큰 register 안에 있을 수 있습니다. `regshifts`는 실제 IPMI data에 맞추기 위해 shift할 bit 수입니다.
`slave_addrs`는 local BMC의 IPMI address입니다. 보통 `0x20`이고 기본값도 `0x20`이지만 다르면 startup 때 지정합니다. 원문 parameter list의 `force_kipmid`가 kernel IPMI daemon을 강제로 enable(1) 또는 disable(0)합니다. Driver가 보통 자동 판단하지만 broken interrupt system은 enable이 필요할 수 있고, performance보다 CPU 절약을 원하는 사용자는 disable할 수 있습니다.
`unload_when_empty=1`이면 interface를 찾지 못하거나 모두 실패할 때 module을 unload합니다. 기본값은 1이며 hotmod를 사용할 때는 0이 유용합니다. 이 option은 module일 때만 의미가 있습니다.
Hardware resource와 register layout parameter를 정리했습니다.
Discovery source와 empty module 처리 흐름입니다.
SI built-in·polling·hotmod
462-521SI driver를 kernel에 built-in하면 module parameter와 같은 이름을 `ipmi_si.` prefix로 kernel command line에 지정합니다.
ipmi_si.type=<type1>,<type2>...
ipmi_si.ports=<port1>,<port2>... ipmi_si.addrs=<addr1>,<addr2>...
ipmi_si.irqs=<irq1>,<irq2>...
ipmi_si.regspacings=<sp1>,<sp2>,...
ipmi_si.regsizes=<size1>,<size2>,...
ipmi_si.regshifts=<shift1>,<shift2>,...
ipmi_si.slave_addrs=<addr1>,<addr2>,...
ipmi_si.force_kipmid=<enable1>,<enable2>,...
ipmi_si.kipmid_max_busy_us=<ustime1>,<ustime2>,...KCS 또는 SMIC interface가 interrupt를 지원하지 않으면 driver가 operation 진행 중 interface를 계속 poll하는 low-priority kernel thread `kipmid`를 시작해 성능을 높입니다. `force_kipmid`로 강제 on/off할 수 있지만 interrupt가 없는데 off로 강제하면 driver가 매우 느려집니다.
Interface 성능에 따라 polling thread가 CPU를 많이 사용해 idle detection과 power consumption에 영향을 줄 수 있습니다. `kipmid_max_busy_us`는 kipmid가 한 tick sleep하기 전 spin할 최대 microsecond를 정합니다. Performance와 CPU 낭비 사이 균형을 workload에 맞춰 조정해야 합니다.
Runtime hot add/remove는 write-only `/sys/modules/ipmi_si/parameters/hotmod`에 operation string을 써서 수행합니다. 한 줄에 여러 interface를 지정할 수 있습니다.
<op1>[:op2[:op3...]]add|remove,kcs|bt|smic,mem|i/o,<address>[,<opt1>[,<opt2>[,...]]]rsp=<regspacing>
rsi=<regsize>
rsh=<regshift>
irq=<irq>
ipmb=<ipmb slave addr>`rsp`, `rsi`, `rsh`, `irq`, `ipmb` option은 앞에서 설명한 register spacing, size, shift, interrupt, IPMB slave address와 같은 의미입니다. Compact interface specification으로 kernel command line에서도 사용할 수 있습니다. Remove 비교에는 SI type, address type, address의 첫 세 parameter만 사용하고 option은 무시합니다.
Interrupt availability와 CPU·latency trade-off입니다.
Write-only sysfs parameter가 interface lifecycle을 바꿉니다.
SMBus driver (SSIF)
522-590SMBus driver는 system에 SMBus device를 최대 4개 구성합니다. 기본적으로 DMI 또는 ACPI table에서 찾은 device에만 register하며 module load parameter로 직접 바꿀 수 있습니다.
modprobe ipmi_ssif.o
addr=<i2caddr1>[,<i2caddr2>[,...]]
adapter=<adapter1>[,<adapter2>[...]]
dbg=<flags1>,<flags2>...
slave_addrs=<addr1>,<addr2>,...
tryacpi=[0|1] trydmi=[0|1]
[dbg_probe=1]
alerts_broken`addr`은 normal I2C address입니다. `adapter`는 `/sys/bus/i2c/devices/i2c-<n>/name`에 표시되는 adapter string name이며 `i2c-<n>` 자체가 아닙니다. 비교는 space를 무시하므로 space가 있는 name도 붙여서 parameter로 전달할 수 있습니다.
BMC별 `dbg` bit flag는 IPMI message 1, driver state 2, timing 4, I2C probe 8입니다. `tryacpi`, `trydmi`는 해당 source의 detection을 disable할 수 있고, `dbg_probe=1`은 SMBus BMC probing·detection debug를 enable합니다. `slave_addrs`는 local BMC IPMI address로 기본값은 보통 `0x20`입니다.
`alerts_broken`을 지정하면 SSIF의 SMBus alert를 enable하지 않습니다. 지정하지 않으면 지원 hardware에서 alert를 enable합니다.
SMBus에서 compliant BMC를 discovery하는 과정은 I2C bus의 다른 device를 실패하게 할 수 있습니다. Driver가 `Get Device ID` IPMI message를 I2C block write로 보내고 response를 기다리기 때문입니다. DMI/ACPI가 address를 제공하지 않는다면 알려진 I2C address를 driver parameter로 명시하는 것이 강하게 권장됩니다.
Built-in driver는 kernel command line에 같은 option을 `ipmi_ssif.` prefix로 지정합니다. 원문 첫 address 예시는 `ipmb_ssif.addr`로 표기되어 있으며 그대로 보존합니다.
ipmb_ssif.addr=<i2caddr1>[,<i2caddr2>[...]]
ipmi_ssif.adapter=<adapter1>[,<adapter2>[...]]
ipmi_ssif.dbg=<flags1>[,<flags2>[...]]
ipmi_ssif.dbg_probe=1
ipmi_ssif.slave_addrs=<addr1>[,<addr2>[...]]
ipmi_ssif.tryacpi=[0|1] ipmi_ssif.trydmi=[0|1]I2C driver는 non-blocking access나 polling을 지원하지 않으므로 special patch와 modification 없이는 panic event, panic 때 watchdog extension 등 panic-related IPMI 기능을 수행할 수 없습니다. Interface hot add/remove는 I2C sysfs interface를 통해 지원합니다.
SMBus BMC discovery·debug 설정입니다.
Blind probe가 다른 I2C device에 미칠 위험을 줄입니다.
IPMI IPMB driver
591-629이 driver는 IPMB bus 위에 있는 system을 지원하며 해당 interface를 normal IPMI interface처럼 보이게 합니다. System-interface address message를 보내면 system에 등록된 BMC, 기본 IPMI address `0x20`으로 전달합니다.
IPMB direct addressing으로 bus의 다른 MC를 직접 address할 수도 있습니다. 다른 MC가 보낸 command는 앞에서 설명한 normal received-command mechanism으로 처리됩니다.
ipmi_ipmb.bmcaddr=<address to use for system interface addresses messages>
ipmi_ipmb.retry_time_ms=<Time between retries on IPMB>
ipmi_ipmb.max_retries=<Number of times to retry a message>Module load만으로는 device tree 설정이 없는 driver가 자동 시작되지 않습니다. 수동 instantiation에는 I2C sysfs `new_device`를 사용합니다.
echo ipmi-ipmb <addr> > /sys/class/i2c-dev/i2c-<n>/device/new_device여기서 `<addr>`은 IPMI address가 아니라 I2C address입니다. MC address를 `0x60`으로 만들려면 I2C address `0x30`을 써야 합니다.
이 interface를 통한 다른 IPMB bus로의 command bridging은 동작하지 않습니다. Receive message queue도 의도적으로 구현하지 않았습니다. BMC에는 host driver용 receive queue 하나만 있기 때문입니다.
BMC는 IPMB bus를 여러 개 가질 수 있고 device가 어느 bus에 있는지는 wiring에 달려 있습니다. `ipmitool channel info <n>`으로 0~7 channel을 조회해 IPMB channel을 확인할 수 있습니다.
System interface address와 direct address가 bus에서 다른 route를 사용합니다.
IPMB의 8-bit IPMI address와 7-bit I2C instantiation 값을 구분합니다.
IPMI device 상세 정보
630-659일부 user는 address discovery source나 IPMI interface의 raw base device처럼 더 자세한 정보가 필요합니다. IPMI `smi_watcher`로 interface add/remove를 감시하고 `ipmi_get_smi_info()`로 다음 구조체를 얻을 수 있습니다.
struct ipmi_smi_info {
enum ipmi_addr_src addr_src;
struct device *dev;
union {
struct {
void *acpi_handle;
} acpi_info;
} addr_info;
};현재 special address information은 `SI_ACPI` source에 대해서만 반환하며 필요에 따라 다른 source가 추가될 수 있습니다. Structure에 `dev` pointer가 포함되므로 `ipmi_get_smi_info()`가 success를 반환했다면 반드시 그 pointer에 `put_device()`를 호출해야 합니다.
Watcher에서 device reference를 얻고 해제하는 순서입니다.
Watchdog
660-737`ipmi_watchdog`는 Linux standard watchdog timer interface를 구현하며 module parameter로 timeout, pretimeout, timeout action, preaction, preop, 즉시 시작, nowayout, interface, panic timeout을 제어합니다.
modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
preaction=<preaction type> preop=<preop type> start_now=x
nowayout=x ifnum_to_use=n panic_wdt_timeout=<t>`ifnum_to_use`는 watchdog이 사용할 interface를 지정합니다. 기본값 `-1`은 처음 등록된 interface를 선택합니다. `timeout`은 final action까지의 초이고 `pretimeout`은 final timeout보다 몇 초 먼저 pre-timeout을 발생시킬지 정합니다. 예를 들어 timeout 50, pretimeout 10이면 40초에 pretimeout이 발생합니다. `pretimeout=0`이면 disable합니다. `panic_wdt_timeout`은 kdump 같은 panic action이 수행될 시간을 확보하도록 kernel panic 때 설정할 timeout입니다.
Final `action`은 `reset`, `power_cycle`, `power_off` 중 하나이며 기본값은 `reset`입니다. `preaction`은 SMI indication인 `pre_smi`, interrupt를 동반한 SMI indication인 `pre_int`, NMI인 `pre_nmi` 중 하나로 driver가 pretimeout을 인식하는 방식을 정합니다.
`preop`은 아무 동작도 하지 않는 `preop_none`, panic하는 `preop_panic`, watchdog device에서 읽을 data를 제공하는 `preop_give_data` 중 하나입니다. NMI context에서는 data operation을 할 수 없으므로 `pre_nmi`와 `preop_give_data`를 함께 사용할 수 없습니다.
`preop_give_data`이면 pretimeout 때 device에서 읽을 1 byte가 준비되고 `select`와 `fasync`도 동작합니다. `start_now=1`이면 driver load 즉시 watchdog을 시작합니다.
`nowayout=1`이면 watchdog device를 닫아도 timer가 멈추지 않습니다. 기본값은 `CONFIG_WATCHDOG_NOWAYOUT`이 enable이면 true, 아니면 false입니다. Built-in driver는 같은 option을 kernel command line으로 받습니다.
ipmi_watchdog.timeout=<t> ipmi_watchdog.pretimeout=<t>
ipmi_watchdog.action=<action type>
ipmi_watchdog.preaction=<preaction type>
ipmi_watchdog.preop=<preop type>
ipmi_watchdog.start_now=x
ipmi_watchdog.nowayout=x
ipmi_watchdog.panic_wdt_timeout=<t>Watchdog가 pre-action을 받으면 panic하고 120초 reset timeout을 시작합니다. Panic 또는 reboot 중에도 watchdog이 이미 실행 중이면 reboot 완료를 보장하도록 120초 timer를 시작합니다.
Watchdog에 NMI preaction을 사용한다면 NMI watchdog을 함께 사용하면 안 됩니다. IPMI controller가 보낸 NMI인지 합리적으로 판별할 방법이 없어, 다른 handler가 처리하지 않은 NMI를 IPMI에서 온 것으로 간주하고 즉시 panic하기 때문입니다.
Watchdog device를 open한 뒤 정상적으로 닫아 timer를 정지하려면 device에 문자 `V`를 써야 합니다. 이는 다른 Linux watchdog driver와 같은 semantics입니다.
Pretimeout은 final timeout보다 앞선 상대 시점입니다.
Notification context와 허용 operation 조합입니다.
nowayout과 magic close 문자를 구분합니다.
Panic timeout과 event log
738-784OpenIPMI driver는 panic 때 system event log에 semi-custom 또는 custom event를 넣을 수 있습니다. `Generate a panic event to all BMCs on a panic`을 enable하면 standard IPMI format event 하나를 기록하고, `Generate OEM events containing the panic string`을 enable하면 panic string을 담은 여러 OEM event도 기록합니다.
Standard panic event field는 Generator ID `0x21`(kernel), EvM Rev `0x03`(IPMI 1.0 format), Sensor Type `0x20`(OS critical stop), Sensor number는 panic string 첫 byte 또는 string이 없으면 0, Event Dir·Type `0x6f`, Event Data 1 `0xa1`, Data 2와 3은 panic string 둘째·셋째 byte입니다. Event는 항상 local management controller로 보내며 controller가 적절한 destination으로 route합니다.
OEM non-timestamped record는 SEL이 정하는 Record ID bytes 0~1, Record type byte 2의 `0xf0`, panic을 저장하는 card의 slave address byte 3, 0부터 증가하는 sequence byte 4, 나머지 11 bytes의 panic string으로 구성됩니다. String이 11 bytes보다 길면 sequence를 증가시키며 여러 message를 보냅니다.
Standard interface로 OEM event를 보낼 수 없으므로 driver는 SEL을 찾아 직접 추가합니다. 먼저 local management controller capability를 조회해 SEL이 있으면 local SEL에 저장합니다. Local controller에 SEL은 없지만 event generator라면 event receiver를 조회해 그 device의 SEL로 보냅니다. 둘 다 아니면 보낼 곳이 없어 event가 저장되지 않습니다.
IPMI 1.0 format의 panic event field입니다.
SEL capability에 따라 저장 위치를 결정합니다.
Poweroff
785-807Poweroff capability를 선택하면 `ipmi_poweroff` module이 standard poweroff function pointer에 shutdown function을 설치합니다. System이 powerdown을 요청하면 platform에 맞는 IPMI command를 전송합니다.
`poweroff_powercycle` module parameter가 0이면 power down, 0이 아니면 system을 끈 뒤 몇 초 후 다시 켜는 power cycle을 수행합니다. Kernel command line의 `ipmi_poweroff.poweroff_control=x`도 같은 역할을 하며 `/proc/sys/dev/ipmi/poweroff_powercycle`에서도 설정할 수 있습니다. System이 power cycle을 지원하지 않으면 항상 power off합니다.
`ifnum_to_use`는 poweroff code가 사용할 interface를 정하며 기본값 `-1`은 처음 등록된 interface를 선택합니다. ACPI가 enable되어 있으면 system은 IPMI보다 ACPI poweroff를 우선합니다.
ACPI 우선순위와 IPMI fallback 동작입니다.
요약과 해설
ipmi.rst:1-807Linux IPMI stack은 `ipmi_msghandler`를 중심으로 kernel·userland client와 KCS/SMIC/BT, SMBus, IPMB transport를 분리합니다. 안정적인 운용에는 firmware discovery, message buffer ownership, command registration, polling latency·CPU trade-off, watchdog NMI 제약과 panic SEL routing을 함께 이해해야 합니다.