1 method 1: the payload os supports acpi, 2 method 2: the payload os does not support acpi, Method 1: the payload os supports acpi – Kontron IPMI Firmware User Manual
Page 16: Method 2: the payload os does not support acpi

D R A F T — F O R I N
T E R N A L U S E O N L Y
16
www.kontron.com
User Guide
IPMI Fimware
6.2.1 Method 1: The Payload OS Supports ACPI
Requirements:
»
The ACPI daemon must be active.
»
An ACPI power button event must result in a system shutdown.
Hot swap operation sequence processed by MMC and OS:
»
On command of the carrier controller, the MMC simulates the pressing and release of the
power button to force an ACPI event.
»
The ACPI daemon detects this ACPI event and initiates the shutdown of the payload software
system.
»
At the end of the shutdown, the payload hardware system reports the sleep state to the MMC
by setting the appropriate signal line.
»
The MMC detects the sleep state and reports this to the carrier controller (“quiesced”) so that
the hot swap processing can be continued and finished.
By default the MMC waits endlessly for the sleep state. Please note that some shelf managers or MCHs
use a timeout to simply switch off a module which needs too much time to reach sleep state. As this
might be an undesirable situation, refer to the appropriate manual for further assistance. In any event,
if an endless wait is to be avoided, it is possible to set a timeout time for the module's MMC after which
the system will be switched off unconditionally. For the setting of the timeout refer to refer to the IPMI
Chapter of the AMC module’s user guide.
6.2.2 Method 2: The Payload OS Does Not Support ACPI
Requirements:
»
At system start on the payload side, the Kontron shutdown daemon “grnsd” must be started.
It is included in the Linux board support packages for the board. This daemon communicates
cyclically with the MMC for the exchange of states, commands and acknowledges. For this, it
uses the OEM Module Quiescence Feedback command. In principle, it plays the
same role as the ACPI daemon of Method 1 above.
Hot swap operation sequence processed by MMC and OS:
»
On command of the carrier controller the MMC sets a “shut down request” flag.
»
The “grnsd” daemon recognizes this request in the response to its cyclical OEM Module
Quiescence Feedback
command and initiates the shutdown of the payload software
system.
»
At the end of the shutdown process, the “grnsd” daemon informs the MMC by setting the ap-
propriate flag when calling the OEM Module Quiescence Feedback command.
»
The MMC reports this to the carrier controller so that the hot swap processing can be contin-
ued and finished.