Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
IPMI(4)		       FreeBSD Kernel Interfaces Manual		       IPMI(4)

NAME
     ipmi -- Intelligent Platform Management Interface driver

SYNOPSIS
     ipmi0 at mainbus0
     ipmi0 at acpi?
     ipmi0 at iic?
     ipmi0 at fdt?

DESCRIPTION
     The ipmi term Intelligent Platform	Management refers to autonomous	moni-
     toring and	recovery features implemented directly in platform management
     hardware and firmware.  The key characteristics of	Intelligent Platform
     Management	is that	inventory, monitoring, logging,	and recovery control
     functions are available independent of the	main processor,	BIOS, and op-
     erating system.

     Platform status information can be	obtained and recovery actions initi-
     ated under	situations where vendor	"in-band" management mechanisms	are
     unavailable.  The independent monitoring, logging,	and access functions
     available through IPMI provide a level of manageability built in to the
     platform hardware.	 This can support systems where	there is no systems
     management	software available for a particular operating system.

     At	the heart of the IPMI architecture is a	microcontroller	called the
     Baseboard Management Controller (BMC).  The BMC provides the intelligence
     behind Intelligent	Platform Management.  The BMC manages the interface
     between system management software	and the	platform management hardware,
     provides autonomous monitoring, event logging, and	recovery control and
     serves as the gateway between systems management software and hardware.

IPMI MESSAGING
     IPMI uses message-based interfaces	for the	different interfaces to	the
     platform management subsystems.  All IPMI messages	share the same fields
     in	the message "payload", regardless of the interface (transport) that
     they're transferred over.	IPMI messaging uses a request/response proto-
     col.  IPMI	request	messages are commonly referred to as commands.	The
     use of request/response protocol facilitates the transfer of IPMI mes-
     sages over	different transports.  IPMI commands are grouped into func-
     tional command sets using a field called network function code.  There
     are command sets for sensor and event related commands, chassis commands
     etc.  This	functional grouping makes it easier to organize	and manage the
     assignment	and allocation of command values.

SENSOR MODEL
     Access to monitored information such as temperatures, voltages, fan sta-
     tus etc., is provided via the IPMI	Sensor Model.  Instead of providing
     direct access to the monitoring hardware, IPMI provides access by ab-
     stracted sensor commands such as the "Get Sensor Reading" command,	imple-
     mented via	a management controller.  This approach	isolates the software
     from changes in the platform management hardware implementation.

     Sensors are classified according to the type of readings they provide
     and/or the	type of	events they generate.  A sensor	can return either an
     analog or discrete	reading.  Sensor events	can be discrete	or threshold-
     based.

SYSTEM EVENT LOG AND EVENT MESSAGES
     The BMC provides a	centralized non-volatile System	Event Log, or SEL.
     Having the	SEL and	logging	functions managed by the BMC helps ensure that
     post-mortem logging information is	available should a failure occur that
     disables the systems processor(s).

     A set of IPMI commands allows the SEL to be read and cleared and for
     events to be added	to the SEL.  The common	request	message	(command) used
     for adding	events to the SEL is referred to as an Event Message.

SENSOR DATA RECORDS & CAPABILITIES COMMANDS
     IPMI's extensibility and scalability mean that each platform implementa-
     tion can have a different population of management	controllers and	sen-
     sors and different	event generation capabilities.	The design of IPMI al-
     lows system management software to	retrieve information from the platform
     and automatically configure itself	to the platform's capabilities.

     Information that describes	the platform management	capabilities is	pro-
     vided via two mechanisms: Capabilities Commands and Sensor	Data Records
     (SDRs).  Capabilities commands are	commands within	the IPMI command sets
     that return fields	that provide information on other commands and func-
     tions the controller can handle.

SYSTEMS	INTERFACES
     IPMI defines three	standardized systems interfaces	that systems software
     uses for transferring IPMI	messages to the	BMC.  In order to support a
     variety of	microcontrollers, IPMI offers a	choice of systems interfaces.
     The system	interfaces are similar enough so that a	single driver can han-
     dle all IPMI system interfaces.

     Keyboard Controller Style (KCS)
	     The bit definitions and operation of the registers	follows	that
	     used in the Intel 8742 Universal Peripheral Interface microcon-
	     troller.  The term	"Keyboard Controller Style" reflects the fact
	     that the 8742 interface was used as the legacy keyboard con-
	     troller interface in PC architecture computer systems.  This in-
	     terface is	available built	in to several commercially available
	     microcontrollers.	Data is	transferred across the KCS interface
	     using a per-byte handshake.

     System Management Interface Chip (SMIC)
	     The SMIC interface	provides an alternative	when the implementer
	     wishes to use a microcontroller for the BMC that does not have
	     the built-in hardware for a KCS interface.	 This interface	is a
	     three I/O port interface that can be implemented using a simple
	     ASIC, FPGA, or discrete logic devices.  It	may also be built in
	     to	a custom-designed management controller.  Like the KCS inter-
	     face, a per-byte handshake	is also	used for transferring data
	     across the	SMIC interface.

     Block Transfer (BT)
	     This interface provides a higher performance system interface op-
	     tion.  Unlike the KCS and SMIC interfaces,	a per-block handshake
	     is	used for transferring data across the interface.  The BT in-
	     terface also provides an alternative to using a controller	with a
	     built-in KCS interface.  The BT interface has three I/O mapped
	     ports.  A typical implementation includes hardware	buffers	for
	     holding upstream and downstream message blocks.  The BT interface
	     can be implemented	using an ASIC or FPGA or may be	built in to a
	     custom-designed management	controller.

     SMBus System Interface (SSIF)
	     The SSIF interface	provides access	to the BMC over	an SMBus in-
	     terface.

WATCHDOG
     IPMI provides watchdog(4) timer functionality.  Once configured, if the
     watchdog is not reset within a certain period of time, it will timeout
     and the server will reset.	 The reset will	occur regardless of the	recov-
     erability of the hang or crash.

     Example of	enabling a watchdog:

	   # sysctl kern.watchdog.period=10

     In	this case if the watchdog is not reset,	it'll reboot the server	after
     roughly 10	seconds.

     Example of	disabling the watchdog:

	   # sysctl kern.watchdog.period=0

SEE ALSO
     watchdog(4), sensorsd(8), sysctl(8)

HISTORY
     The ipmi driver first appeared in OpenBSD 3.9 and conforms	to the IPMI
     1.5 specification.

AUTHORS
     The ipmi driver was written by Jordan Hargrave <jordan@openbsd.org>.

FreeBSD	13.0			March 29, 2020			  FreeBSD 13.0

NAME | SYNOPSIS | DESCRIPTION | IPMI MESSAGING | SENSOR MODEL | SYSTEM EVENT LOG AND EVENT MESSAGES | SENSOR DATA RECORDS & CAPABILITIES COMMANDS | SYSTEMS INTERFACES | WATCHDOG | SEE ALSO | HISTORY | AUTHORS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=ipmi&sektion=4&manpath=OpenBSD+6.9>

home | help