| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Tested By:
Was able to sucessfully build post-code-manager using meson
& was able to see that the daemon is working as before on a
BMC.
Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>
Change-Id: I4cf90fc8bf0a3350b944d5ef94fa131cb6f1c35f
|
|
Change-Id: I9116ed7260e369136acb39eec15075db2d4dbeba
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
|
|
MaxBootCycleCount is a dbus property that is used to indicate
the maximum number of boot cycles that the post-code-manager
daemon can store the progress codes for, before it starts
wrapping.
Unlike Intel postcodes, IBM progress codes are huge and it is
possible to get close to 230+ progress codes per boot cycle, so
tweaking this value to 5 boot cycles for IBM systems so that
we can get less number of log entries on a redfish GET request.
Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>
Change-Id: Ida10e73992b01535d57c844d83366d786cd448e2
|
|
Change-Id: I4453f9b01f986a529c76710d665ab57639232b2d
Signed-off-by: Anton D. Kachalov <gmouse@google.com>
|
|
This new phosphor-state-manager package allows a user to track the state
of their hypervisor firmware. This new software utilizes the
BootProgress property to determine the hypervisor state and relies on a
different software entity (for example PLDM) to monitor state requests
and send the appropriate messages to the hypervisor firmware.
Includes the autobump which has the new function:
phosphor-state-manager: srcrev bump 58477b5287..75f38ee42d
Andrew Geissler (3):
hypervisor: state management support
hypervisor: monitor boot progress
hypervisor: reset requested host state on power off
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I4c4bfc06db3b38b114c28692db808cffceff628a
|
|
The plan on IBM systems is that the host software will communicate via
PLDM which will utilize the D-Bus properties provided by this function.
Note that the new D-Bus interfaces provided by this function could also
be supported via Redfish. The PowerOnDelaySeconds and
PowerOffDelaySeconds properties within the ComputerSystem object would
map to what's provided here. There are no plans currently to do this
though as IBM's only use case is controlling this function via the
in-band PLDM interface.
Tested:
- Verified the generated image had scheduling service and function
worked as expected scheduling a power on then power off
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I781dfba0871853feafed49faa72bf1c05f657d85
|
|
The concept of warm reboot (reboot the host without removing chassis
power) was added a while back as a part of clarifying support for
the Redfish ComputerSystem.Reset Action. It has since been found that
some IBM hardware, including Witherspoon, does not support warm reboots.
The issue is intermittent and depends on the reboot being requested
while the host is in the middle of some i2c transactions. If a warm
reboot occurs during this window, then on the subsequent boot the i2c
hardware will be in a bad state and the host firmware is unable to
recover it.
Given this issue, it has been requested that BMC software go back to
doing cold reboots (cycling power to the chassis during any reboot
request) on this hardware.
The issue has only been reported on Witherspoon so for now only disable
it on that platform.
Tested:
- Verified within QEMU that an image with this commit used the cold reboot
target during a warm reboot request
(From meta-ibm rev: 567a8dcf84dfb74e7bd27d6239be2878fcacdde6)
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I8d77c5e8bf7378a3d1accc79b510f14626a333e5
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
