^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) The Linux IPMI Driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) :Author: Corey Minyard <minyard@mvista.com> / <minyard@acm.org>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) The Intelligent Platform Management Interface, or IPMI, is a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) standard for controlling intelligent devices that monitor a system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) It provides for dynamic discovery of sensors in the system and the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) ability to monitor the sensors and be informed when the sensor's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) values change or go outside certain boundaries. It also has a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) standardized database for field-replaceable units (FRUs) and a watchdog
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) timer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) To use this, you need an interface to an IPMI controller in your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) system (called a Baseboard Management Controller, or BMC) and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) management software that can use the IPMI system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) This document describes how to use the IPMI driver for Linux. If you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) are not familiar with IPMI itself, see the web site at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) https://www.intel.com/design/servers/ipmi/index.htm. IPMI is a big
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) subject and I can't cover it all here!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) Configuration
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) The Linux IPMI driver is modular, which means you have to pick several
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) things to have it work right depending on your hardware. Most of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) these are available in the 'Character Devices' menu then the IPMI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) menu.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) No matter what, you must pick 'IPMI top-level message handler' to use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) IPMI. What you do beyond that depends on your needs and hardware.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) The message handler does not provide any user-level interfaces.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) Kernel code (like the watchdog) can still use it. If you need access
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) from userland, you need to select 'Device interface for IPMI' if you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) want access through a device driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) The driver interface depends on your hardware. If your system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) properly provides the SMBIOS info for IPMI, the driver will detect it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) and just work. If you have a board with a standard interface (These
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) will generally be either "KCS", "SMIC", or "BT", consult your hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) manual), choose the 'IPMI SI handler' option. A driver also exists
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) for direct I2C access to the IPMI management controller. Some boards
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) support this, but it is unknown if it will work on every board. For
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) this, choose 'IPMI SMBus handler', but be ready to try to do some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) figuring to see if it will work on your system if the SMBIOS/APCI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) information is wrong or not present. It is fairly safe to have both
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) these enabled and let the drivers auto-detect what is present.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) You should generally enable ACPI on your system, as systems with IPMI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) can have ACPI tables describing them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) If you have a standard interface and the board manufacturer has done
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) their job correctly, the IPMI controller should be automatically
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) detected (via ACPI or SMBIOS tables) and should just work. Sadly,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) many boards do not have this information. The driver attempts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) standard defaults, but they may not work. If you fall into this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) situation, you need to read the section below named 'The SI Driver' or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) "The SMBus Driver" on how to hand-configure your system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) IPMI defines a standard watchdog timer. You can enable this with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) 'IPMI Watchdog Timer' config option. If you compile the driver into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) the kernel, then via a kernel command-line option you can have the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) watchdog timer start as soon as it initializes. It also have a lot
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) of other options, see the 'Watchdog' section below for more details.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) Note that you can also have the watchdog continue to run if it is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) closed (by default it is disabled on close). Go into the 'Watchdog
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) Cards' menu, enable 'Watchdog Timer Support', and enable the option
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) 'Disable watchdog shutdown on close'.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) IPMI systems can often be powered off using IPMI commands. Select
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) 'IPMI Poweroff' to do this. The driver will auto-detect if the system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) can be powered off by IPMI. It is safe to enable this even if your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) system doesn't support this option. This works on ATCA systems, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) Radisys CPI1 card, and any IPMI system that supports standard chassis
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) management commands.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) If you want the driver to put an event into the event log on a panic,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) enable the 'Generate a panic event to all BMCs on a panic' option. If
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) you want the whole panic string put into the event log using OEM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) events, enable the 'Generate OEM events containing the panic string'
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) option. You can also enable these dynamically by setting the module
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) parameter named "panic_op" in the ipmi_msghandler module to "event"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) or "string". Setting that parameter to "none" disables this function.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) Basic Design
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) ------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) The Linux IPMI driver is designed to be very modular and flexible, you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) only need to take the pieces you need and you can use it in many
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) different ways. Because of that, it's broken into many chunks of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) code. These chunks (by module name) are:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) ipmi_msghandler - This is the central piece of software for the IPMI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) system. It handles all messages, message timing, and responses. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) IPMI users tie into this, and the IPMI physical interfaces (called
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) System Management Interfaces, or SMIs) also tie in here. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) provides the kernelland interface for IPMI, but does not provide an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) interface for use by application processes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) ipmi_devintf - This provides a userland IOCTL interface for the IPMI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) driver, each open file for this device ties in to the message handler
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) as an IPMI user.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) ipmi_si - A driver for various system interfaces. This supports KCS,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) SMIC, and BT interfaces. Unless you have an SMBus interface or your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) own custom interface, you probably need to use this.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) ipmi_ssif - A driver for accessing BMCs on the SMBus. It uses the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) I2C kernel driver's SMBus interfaces to send and receive IPMI messages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) over the SMBus.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) ipmi_powernv - A driver for access BMCs on POWERNV systems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) ipmi_watchdog - IPMI requires systems to have a very capable watchdog
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) timer. This driver implements the standard Linux watchdog timer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) interface on top of the IPMI message handler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) ipmi_poweroff - Some systems support the ability to be turned off via
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) IPMI commands.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) bt-bmc - This is not part of the main driver, but instead a driver for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) accessing a BMC-side interface of a BT interface. It is used on BMCs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) running Linux to provide an interface to the host.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) These are all individually selectable via configuration options.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) Much documentation for the interface is in the include files. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) IPMI include files are:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) linux/ipmi.h - Contains the user interface and IOCTL interface for IPMI.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) linux/ipmi_smi.h - Contains the interface for system management interfaces
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) (things that interface to IPMI controllers) to use.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) linux/ipmi_msgdefs.h - General definitions for base IPMI messaging.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) Addressing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) ----------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) The IPMI addressing works much like IP addresses, you have an overlay
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) to handle the different address types. The overlay is::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) struct ipmi_addr
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) int addr_type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) short channel;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) char data[IPMI_MAX_ADDR_SIZE];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) The addr_type determines what the address really is. The driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) currently understands two different types of addresses.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) "System Interface" addresses are defined as::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) struct ipmi_system_interface_addr
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) int addr_type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) short channel;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) and the type is IPMI_SYSTEM_INTERFACE_ADDR_TYPE. This is used for talking
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) straight to the BMC on the current card. The channel must be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) IPMI_BMC_CHANNEL.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) Messages that are destined to go out on the IPMB bus use the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) IPMI_IPMB_ADDR_TYPE address type. The format is::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) struct ipmi_ipmb_addr
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) int addr_type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) short channel;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) unsigned char slave_addr;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) unsigned char lun;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) The "channel" here is generally zero, but some devices support more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) than one channel, it corresponds to the channel as defined in the IPMI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) spec.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) Messages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) --------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) Messages are defined as::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) struct ipmi_msg
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) unsigned char netfn;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) unsigned char lun;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) unsigned char cmd;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) unsigned char *data;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) int data_len;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) The driver takes care of adding/stripping the header information. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) data portion is just the data to be send (do NOT put addressing info
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) here) or the response. Note that the completion code of a response is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) the first item in "data", it is not stripped out because that is how
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) all the messages are defined in the spec (and thus makes counting the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) offsets a little easier :-).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) When using the IOCTL interface from userland, you must provide a block
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) of data for "data", fill it, and set data_len to the length of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) block of data, even when receiving messages. Otherwise the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) will have no place to put the message.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) Messages coming up from the message handler in kernelland will come in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) as::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) struct ipmi_recv_msg
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) struct list_head link;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) /* The type of message as defined in the "Receive Types"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) defines above. */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) int recv_type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) ipmi_user_t *user;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) struct ipmi_addr addr;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) long msgid;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) struct ipmi_msg msg;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) /* Call this when done with the message. It will presumably free
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) the message and do any other necessary cleanup. */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) void (*done)(struct ipmi_recv_msg *msg);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) /* Place-holder for the data, don't make any assumptions about
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) the size or existence of this, since it may change. */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) unsigned char msg_data[IPMI_MAX_MSG_LENGTH];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) You should look at the receive type and handle the message
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) appropriately.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) The Upper Layer Interface (Message Handler)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) -------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) The upper layer of the interface provides the users with a consistent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) view of the IPMI interfaces. It allows multiple SMI interfaces to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) addressed (because some boards actually have multiple BMCs on them)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) and the user should not have to care what type of SMI is below them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) Watching For Interfaces
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) ^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) When your code comes up, the IPMI driver may or may not have detected
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) if IPMI devices exist. So you might have to defer your setup until
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) the device is detected, or you might be able to do it immediately.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) To handle this, and to allow for discovery, you register an SMI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) watcher with ipmi_smi_watcher_register() to iterate over interfaces
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) and tell you when they come and go.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) Creating the User
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) ^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) To use the message handler, you must first create a user using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) ipmi_create_user. The interface number specifies which SMI you want
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) to connect to, and you must supply callback functions to be called
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) when data comes in. The callback function can run at interrupt level,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) so be careful using the callbacks. This also allows to you pass in a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) piece of data, the handler_data, that will be passed back to you on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) all calls.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) Once you are done, call ipmi_destroy_user() to get rid of the user.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) From userland, opening the device automatically creates a user, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) closing the device automatically destroys the user.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) Messaging
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) ^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) To send a message from kernel-land, the ipmi_request_settime() call does
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) pretty much all message handling. Most of the parameter are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) self-explanatory. However, it takes a "msgid" parameter. This is NOT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) the sequence number of messages. It is simply a long value that is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) passed back when the response for the message is returned. You may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) use it for anything you like.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) Responses come back in the function pointed to by the ipmi_recv_hndl
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) field of the "handler" that you passed in to ipmi_create_user().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) Remember again, these may be running at interrupt level. Remember to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) look at the receive type, too.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) From userland, you fill out an ipmi_req_t structure and use the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) IPMICTL_SEND_COMMAND ioctl. For incoming stuff, you can use select()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) or poll() to wait for messages to come in. However, you cannot use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) read() to get them, you must call the IPMICTL_RECEIVE_MSG with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) ipmi_recv_t structure to actually get the message. Remember that you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) must supply a pointer to a block of data in the msg.data field, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) you must fill in the msg.data_len field with the size of the data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) This gives the receiver a place to actually put the message.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) If the message cannot fit into the data you provide, you will get an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) EMSGSIZE error and the driver will leave the data in the receive
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) queue. If you want to get it and have it truncate the message, us
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) the IPMICTL_RECEIVE_MSG_TRUNC ioctl.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) When you send a command (which is defined by the lowest-order bit of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) the netfn per the IPMI spec) on the IPMB bus, the driver will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308) automatically assign the sequence number to the command and save the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) command. If the response is not receive in the IPMI-specified 5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) seconds, it will generate a response automatically saying the command
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) timed out. If an unsolicited response comes in (if it was after 5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) seconds, for instance), that response will be ignored.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) In kernelland, after you receive a message and are done with it, you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) MUST call ipmi_free_recv_msg() on it, or you will leak messages. Note
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) that you should NEVER mess with the "done" field of a message, that is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) required to properly clean up the message.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) Note that when sending, there is an ipmi_request_supply_msgs() call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) that lets you supply the smi and receive message. This is useful for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) pieces of code that need to work even if the system is out of buffers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) (the watchdog timer uses this, for instance). You supply your own
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) buffer and own free routines. This is not recommended for normal use,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) though, since it is tricky to manage your own buffers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) Events and Incoming Commands
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) The driver takes care of polling for IPMI events and receiving
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) commands (commands are messages that are not responses, they are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) commands that other things on the IPMB bus have sent you). To receive
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) these, you must register for them, they will not automatically be sent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334) to you.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) To receive events, you must call ipmi_set_gets_events() and set the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) "val" to non-zero. Any events that have been received by the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) since startup will immediately be delivered to the first user that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) registers for events. After that, if multiple users are registered
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) for events, they will all receive all events that come in.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) For receiving commands, you have to individually register commands you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) want to receive. Call ipmi_register_for_cmd() and supply the netfn
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) and command name for each command you want to receive. You also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) specify a bitmask of the channels you want to receive the command from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) (or use IPMI_CHAN_ALL for all channels if you don't care). Only one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) user may be registered for each netfn/cmd/channel, but different users
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) may register for different commands, or the same command if the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) channel bitmasks do not overlap.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) From userland, equivalent IOCTLs are provided to do these functions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) The Lower Layer (SMI) Interface
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) -------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) As mentioned before, multiple SMI interfaces may be registered to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) message handler, each of these is assigned an interface number when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) they register with the message handler. They are generally assigned
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) in the order they register, although if an SMI unregisters and then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) another one registers, all bets are off.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) The ipmi_smi.h defines the interface for management interfaces, see
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) that for more details.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) The SI Driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) The SI driver allows KCS, BT, and SMIC interfaces to be configured
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371) in the system. It discovers interfaces through a host of different
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) methods, depending on the system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) You can specify up to four interfaces on the module load line and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) control some module parameters::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) modprobe ipmi_si.o type=<type1>,<type2>....
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) irqs=<irq1>,<irq2>...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) regshifts=<shift1>,<shift2>,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) slave_addrs=<addr1>,<addr2>,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383) force_kipmid=<enable1>,<enable2>,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384) kipmid_max_busy_us=<ustime1>,<ustime2>,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) unload_when_empty=[0|1]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) trydmi=[0|1] tryacpi=[0|1]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) tryplatform=[0|1] trypci=[0|1]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) Each of these except try... items is a list, the first item for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390) first interface, second item for the second interface, etc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) defaults to "kcs".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) If you specify addrs as non-zero for an interface, the driver will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) use the memory address given as the address of the device. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) overrides si_ports.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399) If you specify ports as non-zero for an interface, the driver will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) use the I/O port given as the device address.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) If you specify irqs as non-zero for an interface, the driver will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) attempt to use the given interrupt for the device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) The other try... items disable discovery by their corresponding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406) names. These are all enabled by default, set them to zero to disable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) them. The tryplatform disables openfirmware.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409) The next three parameters have to do with register layout. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) registers used by the interfaces may not appear at successive
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) locations and they may not be in 8-bit registers. These parameters
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) allow the layout of the data in the registers to be more precisely
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) specified.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) The regspacings parameter give the number of bytes between successive
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416) register start addresses. For instance, if the regspacing is set to 4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) and the start address is 0xca2, then the address for the second
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) register would be 0xca6. This defaults to 1.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) The regsizes parameter gives the size of a register, in bytes. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) data used by IPMI is 8-bits wide, but it may be inside a larger
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) register. This parameter allows the read and write type to specified.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) It may be 1, 2, 4, or 8. The default is 1.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) Since the register size may be larger than 32 bits, the IPMI data may not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426) be in the lower 8 bits. The regshifts parameter give the amount to shift
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) the data to get to the actual IPMI data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429) The slave_addrs specifies the IPMI address of the local BMC. This is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) usually 0x20 and the driver defaults to that, but in case it's not, it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) can be specified when the driver starts up.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433) The force_ipmid parameter forcefully enables (if set to 1) or disables
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) (if set to 0) the kernel IPMI daemon. Normally this is auto-detected
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) by the driver, but systems with broken interrupts might need an enable,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) or users that don't want the daemon (don't need the performance, don't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437) want the CPU hit) can disable it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439) If unload_when_empty is set to 1, the driver will be unloaded if it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440) doesn't find any interfaces or all the interfaces fail to work. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441) default is one. Setting to 0 is useful with the hotmod, but is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) obviously only useful for modules.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444) When compiled into the kernel, the parameters can be specified on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) kernel command line as::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447) ipmi_si.type=<type1>,<type2>...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) ipmi_si.ports=<port1>,<port2>... ipmi_si.addrs=<addr1>,<addr2>...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449) ipmi_si.irqs=<irq1>,<irq2>...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) ipmi_si.regspacings=<sp1>,<sp2>,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451) ipmi_si.regsizes=<size1>,<size2>,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452) ipmi_si.regshifts=<shift1>,<shift2>,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) ipmi_si.slave_addrs=<addr1>,<addr2>,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454) ipmi_si.force_kipmid=<enable1>,<enable2>,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) ipmi_si.kipmid_max_busy_us=<ustime1>,<ustime2>,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457) It works the same as the module parameters of the same names.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459) If your IPMI interface does not support interrupts and is a KCS or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460) SMIC interface, the IPMI driver will start a kernel thread for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) interface to help speed things up. This is a low-priority kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462) thread that constantly polls the IPMI driver while an IPMI operation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463) is in progress. The force_kipmid module parameter will all the user to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) force this thread on or off. If you force it off and don't have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465) interrupts, the driver will run VERY slowly. Don't blame me,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) these interfaces suck.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468) Unfortunately, this thread can use a lot of CPU depending on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469) interface's performance. This can waste a lot of CPU and cause
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470) various issues with detecting idle CPU and using extra power. To
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) avoid this, the kipmid_max_busy_us sets the maximum amount of time, in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) microseconds, that kipmid will spin before sleeping for a tick. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473) value sets a balance between performance and CPU waste and needs to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474) tuned to your needs. Maybe, someday, auto-tuning will be added, but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) that's not a simple thing and even the auto-tuning would need to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476) tuned to the user's desired performance.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478) The driver supports a hot add and remove of interfaces. This way,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479) interfaces can be added or removed after the kernel is up and running.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480) This is done using /sys/modules/ipmi_si/parameters/hotmod, which is a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) write-only parameter. You write a string to this interface. The string
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482) has the format::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484) <op1>[:op2[:op3...]]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486) The "op"s are::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) add|remove,kcs|bt|smic,mem|i/o,<address>[,<opt1>[,<opt2>[,...]]]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490) You can specify more than one interface on the line. The "opt"s are::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) rsp=<regspacing>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493) rsi=<regsize>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494) rsh=<regshift>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495) irq=<irq>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496) ipmb=<ipmb slave addr>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498) and these have the same meanings as discussed above. Note that you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499) can also use this on the kernel command line for a more compact format
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) for specifying an interface. Note that when removing an interface,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501) only the first three parameters (si type, address type, and address)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) are used for the comparison. Any options are ignored for removing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504) The SMBus Driver (SSIF)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505) -----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 507) The SMBus driver allows up to 4 SMBus devices to be configured in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 508) system. By default, the driver will only register with something it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 509) finds in DMI or ACPI tables. You can change this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 510) at module load time (for a module) with::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 511)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 512) modprobe ipmi_ssif.o
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 513) addr=<i2caddr1>[,<i2caddr2>[,...]]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 514) adapter=<adapter1>[,<adapter2>[...]]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 515) dbg=<flags1>,<flags2>...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 516) slave_addrs=<addr1>,<addr2>,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 517) tryacpi=[0|1] trydmi=[0|1]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 518) [dbg_probe=1]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 519) alerts_broken
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 520)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 521) The addresses are normal I2C addresses. The adapter is the string
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 522) name of the adapter, as shown in /sys/class/i2c-adapter/i2c-<n>/name.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 523) It is *NOT* i2c-<n> itself. Also, the comparison is done ignoring
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 524) spaces, so if the name is "This is an I2C chip" you can say
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 525) adapter_name=ThisisanI2cchip. This is because it's hard to pass in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 526) spaces in kernel parameters.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 527)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 528) The debug flags are bit flags for each BMC found, they are:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 529) IPMI messages: 1, driver state: 2, timing: 4, I2C probe: 8
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 530)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 531) The tryxxx parameters can be used to disable detecting interfaces
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 532) from various sources.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 533)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 534) Setting dbg_probe to 1 will enable debugging of the probing and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 535) detection process for BMCs on the SMBusses.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 536)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 537) The slave_addrs specifies the IPMI address of the local BMC. This is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 538) usually 0x20 and the driver defaults to that, but in case it's not, it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 539) can be specified when the driver starts up.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 540)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 541) alerts_broken does not enable SMBus alert for SSIF. Otherwise SMBus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 542) alert will be enabled on supported hardware.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 543)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 544) Discovering the IPMI compliant BMC on the SMBus can cause devices on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 545) the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 546) message as a block write to the I2C bus and waits for a response.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 547) This action can be detrimental to some I2C devices. It is highly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 548) recommended that the known I2C address be given to the SMBus driver in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 549) the smb_addr parameter unless you have DMI or ACPI data to tell the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 550) driver what to use.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 551)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 552) When compiled into the kernel, the addresses can be specified on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 553) kernel command line as::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 554)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 555) ipmb_ssif.addr=<i2caddr1>[,<i2caddr2>[...]]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 556) ipmi_ssif.adapter=<adapter1>[,<adapter2>[...]]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 557) ipmi_ssif.dbg=<flags1>[,<flags2>[...]]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 558) ipmi_ssif.dbg_probe=1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 559) ipmi_ssif.slave_addrs=<addr1>[,<addr2>[...]]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 560) ipmi_ssif.tryacpi=[0|1] ipmi_ssif.trydmi=[0|1]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 561)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 562) These are the same options as on the module command line.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 563)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 564) The I2C driver does not support non-blocking access or polling, so
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 565) this driver cannod to IPMI panic events, extend the watchdog at panic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 566) time, or other panic-related IPMI functions without special kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 567) patches and driver modifications. You can get those at the openipmi
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 568) web page.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 569)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 570) The driver supports a hot add and remove of interfaces through the I2C
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 571) sysfs interface.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 572)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 573) Other Pieces
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 574) ------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 575)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 576) Get the detailed info related with the IPMI device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 577) --------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 578)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 579) Some users need more detailed information about a device, like where
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 580) the address came from or the raw base device for the IPMI interface.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 581) You can use the IPMI smi_watcher to catch the IPMI interfaces as they
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 582) come or go, and to grab the information, you can use the function
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 583) ipmi_get_smi_info(), which returns the following structure::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 584)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 585) struct ipmi_smi_info {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 586) enum ipmi_addr_src addr_src;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 587) struct device *dev;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 588) union {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 589) struct {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 590) void *acpi_handle;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 591) } acpi_info;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 592) } addr_info;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 593) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 594)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 595) Currently special info for only for SI_ACPI address sources is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 596) returned. Others may be added as necessary.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 597)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 598) Note that the dev pointer is included in the above structure, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 599) assuming ipmi_smi_get_info returns success, you must call put_device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 600) on the dev pointer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 601)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 602)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 603) Watchdog
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 604) --------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 605)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 606) A watchdog timer is provided that implements the Linux-standard
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 607) watchdog timer interface. It has three module parameters that can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 608) used to control it::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 609)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 610) modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 611) preaction=<preaction type> preop=<preop type> start_now=x
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 612) nowayout=x ifnum_to_use=n panic_wdt_timeout=<t>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 613)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 614) ifnum_to_use specifies which interface the watchdog timer should use.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 615) The default is -1, which means to pick the first one registered.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 616)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 617) The timeout is the number of seconds to the action, and the pretimeout
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 618) is the amount of seconds before the reset that the pre-timeout panic will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 619) occur (if pretimeout is zero, then pretimeout will not be enabled). Note
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 620) that the pretimeout is the time before the final timeout. So if the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 621) timeout is 50 seconds and the pretimeout is 10 seconds, then the pretimeout
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 622) will occur in 40 second (10 seconds before the timeout). The panic_wdt_timeout
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 623) is the value of timeout which is set on kernel panic, in order to let actions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 624) such as kdump to occur during panic.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 625)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 626) The action may be "reset", "power_cycle", or "power_off", and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 627) specifies what to do when the timer times out, and defaults to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 628) "reset".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 629)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 630) The preaction may be "pre_smi" for an indication through the SMI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 631) interface, "pre_int" for an indication through the SMI with an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 632) interrupts, and "pre_nmi" for a NMI on a preaction. This is how
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 633) the driver is informed of the pretimeout.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 634)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 635) The preop may be set to "preop_none" for no operation on a pretimeout,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 636) "preop_panic" to set the preoperation to panic, or "preop_give_data"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 637) to provide data to read from the watchdog device when the pretimeout
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 638) occurs. A "pre_nmi" setting CANNOT be used with "preop_give_data"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 639) because you can't do data operations from an NMI.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 640)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 641) When preop is set to "preop_give_data", one byte comes ready to read
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 642) on the device when the pretimeout occurs. Select and fasync work on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 643) the device, as well.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 644)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 645) If start_now is set to 1, the watchdog timer will start running as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 646) soon as the driver is loaded.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 647)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 648) If nowayout is set to 1, the watchdog timer will not stop when the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 649) watchdog device is closed. The default value of nowayout is true
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 650) if the CONFIG_WATCHDOG_NOWAYOUT option is enabled, or false if not.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 651)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 652) When compiled into the kernel, the kernel command line is available
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 653) for configuring the watchdog::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 654)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 655) ipmi_watchdog.timeout=<t> ipmi_watchdog.pretimeout=<t>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 656) ipmi_watchdog.action=<action type>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 657) ipmi_watchdog.preaction=<preaction type>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 658) ipmi_watchdog.preop=<preop type>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 659) ipmi_watchdog.start_now=x
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 660) ipmi_watchdog.nowayout=x
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 661) ipmi_watchdog.panic_wdt_timeout=<t>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 662)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 663) The options are the same as the module parameter options.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 664)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 665) The watchdog will panic and start a 120 second reset timeout if it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 666) gets a pre-action. During a panic or a reboot, the watchdog will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 667) start a 120 timer if it is running to make sure the reboot occurs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 668)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 669) Note that if you use the NMI preaction for the watchdog, you MUST NOT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 670) use the nmi watchdog. There is no reasonable way to tell if an NMI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 671) comes from the IPMI controller, so it must assume that if it gets an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 672) otherwise unhandled NMI, it must be from IPMI and it will panic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 673) immediately.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 674)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 675) Once you open the watchdog timer, you must write a 'V' character to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 676) device to close it, or the timer will not stop. This is a new semantic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 677) for the driver, but makes it consistent with the rest of the watchdog
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 678) drivers in Linux.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 679)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 680)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 681) Panic Timeouts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 682) --------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 683)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 684) The OpenIPMI driver supports the ability to put semi-custom and custom
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 685) events in the system event log if a panic occurs. if you enable the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 686) 'Generate a panic event to all BMCs on a panic' option, you will get
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 687) one event on a panic in a standard IPMI event format. If you enable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 688) the 'Generate OEM events containing the panic string' option, you will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 689) also get a bunch of OEM events holding the panic string.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 690)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 691)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 692) The field settings of the events are:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 693)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 694) * Generator ID: 0x21 (kernel)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 695) * EvM Rev: 0x03 (this event is formatting in IPMI 1.0 format)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 696) * Sensor Type: 0x20 (OS critical stop sensor)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 697) * Sensor #: The first byte of the panic string (0 if no panic string)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 698) * Event Dir | Event Type: 0x6f (Assertion, sensor-specific event info)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 699) * Event Data 1: 0xa1 (Runtime stop in OEM bytes 2 and 3)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 700) * Event data 2: second byte of panic string
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 701) * Event data 3: third byte of panic string
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 702)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 703) See the IPMI spec for the details of the event layout. This event is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 704) always sent to the local management controller. It will handle routing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 705) the message to the right place
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 706)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 707) Other OEM events have the following format:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 708)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 709) * Record ID (bytes 0-1): Set by the SEL.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 710) * Record type (byte 2): 0xf0 (OEM non-timestamped)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 711) * byte 3: The slave address of the card saving the panic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 712) * byte 4: A sequence number (starting at zero)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 713) The rest of the bytes (11 bytes) are the panic string. If the panic string
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 714) is longer than 11 bytes, multiple messages will be sent with increasing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 715) sequence numbers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 716)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 717) Because you cannot send OEM events using the standard interface, this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 718) function will attempt to find an SEL and add the events there. It
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 719) will first query the capabilities of the local management controller.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 720) If it has an SEL, then they will be stored in the SEL of the local
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 721) management controller. If not, and the local management controller is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 722) an event generator, the event receiver from the local management
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 723) controller will be queried and the events sent to the SEL on that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 724) device. Otherwise, the events go nowhere since there is nowhere to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 725) send them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 726)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 727)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 728) Poweroff
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 729) --------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 730)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 731) If the poweroff capability is selected, the IPMI driver will install
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 732) a shutdown function into the standard poweroff function pointer. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 733) is in the ipmi_poweroff module. When the system requests a powerdown,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 734) it will send the proper IPMI commands to do this. This is supported on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 735) several platforms.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 736)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 737) There is a module parameter named "poweroff_powercycle" that may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 738) either be zero (do a power down) or non-zero (do a power cycle, power
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 739) the system off, then power it on in a few seconds). Setting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 740) ipmi_poweroff.poweroff_control=x will do the same thing on the kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 741) command line. The parameter is also available via the proc filesystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 742) in /proc/sys/dev/ipmi/poweroff_powercycle. Note that if the system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 743) does not support power cycling, it will always do the power off.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 744)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 745) The "ifnum_to_use" parameter specifies which interface the poweroff
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 746) code should use. The default is -1, which means to pick the first one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 747) registered.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 748)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 749) Note that if you have ACPI enabled, the system will prefer using ACPI to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 750) power off.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags