Query on implementation of PowerRestoreDelay
#30
Comments
|
Hi Prithvi, The change to prevent the power restore logic from running until BMC_READY can be found at https://gerrit.openbmc.org/c/openbmc/phosphor-state-manager/+/71085. There was some discussion in there on whether anyone found it useful to allow a BMC and host boot in parallel. I didn't know of anyone at the time so we went with the simpler solution to just always wait for BMC_READY before starting the power restore timer. I take it you have a use case where you would like the BMC firmware and host firmware to be allowed to boot at the same time? There are some minimum services that must be running to start a power on but if your system supports the parallel aspect we can do what discussed in that review and only wait for BMC_READY if the corresponding meson option is selected. |
We have a few platforms that handle some of the power logic using a Xilinx or Altera FPGA. This allows the host firmware to begin memory training before the BMC is fully booted, which can take quite a while. If the host firmware were only allowed to start once the BMC was ready, the system would likely take over 25 minutes, instead of 15 minutes, to complete a cold boot and reach the OS (on Pilot4 and AST2500-based systems). |
|
Hi @geissonator,
I query was to check if I m using the right property(i.e |
|
Should we just subtract the uptime from the PowerRestoreDelay if this is the first boot after a BMC reboot? Does that help? |
|
Definition vs. Implementation Discrepancy The [(https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Control/Power/RestorePolicy.interface.yaml) However, the current implementation seems to:
This implementation diverges from the original definition in two key aspects:
Intended Behavior
|
|
@williamspatrick yes, we could do that. But I wanted to make sure if my understanding is right about the PowerRestoreDelay definition. |
|
I think the intention of the definition is correct: we block power on for (at least) N seconds after power is available. But like most code there are also [undocumented] constraints. Malloc is documented to give you a block of memory, except when it can’t. This code will block the power on, but, it also needs to make sure the BMC is ready to handle that power on. I think the big issue here is “what does it mean for the BMC to be ready to handle the host powering on”, which, realistically is a system-specific definition. The safest one is to wait until BMC_READY. A system specific one might be: wait until IPMI is running. But “IPMI is running” isn’t even a great indication because IPMI itself is dependent on other services for its function (but never has an explicit dependency on those services at a service-file level). We’re left with no clear “when is it safe to power on the host” from the BMC perspective other than BMC_READY. (For clarity, most systems that use IPMI require the BMC to respond to IPMI messages during the BIOS boot process or else either the boot fails or the BIOS assumes there is no BMC and doesn’t make IPMI available in the ACPI tables for the kernel, which means the kernel won’t load the IPMI modules. Almost all BMC-managed systems have some dependency on the BMC in this way, which is what the “wait for ready” is trying to address.) |
|
Thanks a lot for your explanation. I agree and understand the requirement of |
This patch introduces the delay defined by the user while restoring `PowerPolicy`. Current implementation delays the Host Power restore until it sees the `BMC_READY` signal. Fixes jira https:// Note: 1) This policy is applied only when `cpu-staging-boot` is enabled. 2) By default, the above meson option is disabled ``` Upstream Discussions on PowerRestoreDelay: openbmc#30 ``` Tested: 1) Case 1: Validate policy `AlwaysOn` with delay and Host State PowerOff ``` Current Host State: PowerOn Request Power Transition: GracefulShutdown PowerPolicy: AlwaysOn PowerRestoreDelay: 120 seconds Result: Host Transition to Power On is triggered after 120 seconds of PSM coming up. ``` 2) Case 2: Validate policy `AlwaysOn` with delay and host state PowerOn ``` Current Host State: PowerOff Request Power Transition: ForceOn PowerPolicy: AlwaysOn PowerRestoreDelay: 120 seconds Result: Host Transition to Power On is triggered after 120 seconds of PSM coming up ``` 3) Case 3: Validate policy `AlwaysOff` with delay and Host State PowerOff ``` Current Host State: PowerOn Request Power Transition: GracefulShutdown PowerPolicy: AlwaysOff PowerRestoreDelay: 120 seconds Result: Host remains in PowerOff state ``` 4) Case 4: Validate policy `AlwaysOff` with delay and Host state PowerOn ``` Current Host State: PowerOff Request Power Transition: ForceOn PowerPolicy: AlwaysOff PowerRestoreDelay: 120 seconds Result: Host remains in PowerOff State ``` ``` Signed-off-by: Prithvi Pai <[email protected]>
Hi Team,
The current implementation of
PowerRestoreDelaydeviates with other BMC components such as redfish andphosphor-dbus-interfaces.The current implementation delays the Host Power restore until it sees the
BMC_READYsignal. However, should it not just wait for the seconds as specified by the user inPowerRestoreDelay?For example:
ComputerSystemschema says:reference: https://redfish.dmtf.org/schemas/v1/ComputerSystem_v1.xml
PowerRestoreDelayreference: https://github.com/openbmc/phosphor-dbus-interfaces/blob/d25367bd9726a479eddbec85c51722d62043c724/yaml/xyz/openbmc_project/Control/Power/RestorePolicy.interface.yaml#L15
Thanks,
Prithvi Pai
The text was updated successfully, but these errors were encountered: