| commit | edd211e4124356eb4186d227bc7f8afcea3d9cfe | [log] [tgz] |
|---|---|---|
| author | Michal Orzel <michalx.orzel@intel.com> | Fri Oct 28 13:10:16 2022 +0200 |
| committer | Michal Orzel <michalx.orzel@intel.com> | Fri Jun 02 12:40:22 2023 +0200 |
| tree | f58e892e5a5243a03433e7b5e926ea9f017d15ea | |
| parent | 891bbde7eb6506a68b690b52b25dfa4f08904e88 [diff] |
Handle possible SdBus exceptions Right now service allows to access several signals using DBus interface, instead of GPIO pins. In case of that option selected in config, service will try to read given DBus property using function getProperty. Unfortunately that attempt might fail, for example when that specific object doesn't exist yet, which will cause with unhandled exception and evantually service restart. This change adds handler for that sort of exception. If read property fails, another one will be scheduled in the next second. That process shall be repeated until value is successfully read. As there are several possible properties to read, each one shall utilize its own timer, so that every failure can be handled independently from each other. Tested: Change has been tested on Intel platform, which showed symptoms described above: service tried to get property which has not yet been created, which caused its crash and restart. With this fix applied, issue stopped reproducing. Change-Id: Ib9b89e07a348868d2f15ffda31b3dc9a47340873 Signed-off-by: Michal Orzel <michalx.orzel@intel.com>
This repository contains an OpenBMC compliant implementation of power control for x86 servers. It relies on a number of features to do its job. It has several intentional design goals.
This daemon has been successfully used on a variety of server platforms; it should be able to support platforms with power control GPIOs similar to those in its config file.
x86-power-control uses default json file (power-config-host0.json) for GPIO configuration. However this can be customized by producing your own power-config-host0.json file.
Definitions can be configured by two type: GPIO and DBUS
For the platform having direct GPIO access can use the type GPIO and define like below.
{ "Name": "PostComplete", "LineName": "POST_COMPLETE", "Type": "GPIO" }
For the platform not having direct GPIO access can use dbus based event monitor by using the type DBUS.
{ "Name": "PowerButton", "DbusName": "xyz.openbmc_project.Chassis.Event", "Path": "/xyz/openbmc_project/Chassis/Event", "Interface": "xyz.openbmc_project.Chassis.Event", "Property": "PowerButton_Host1", "Type": "DBUS" }
x86-power-control will monitor the property change from the given DbusName and take appropriate action. *define Property as a bool variable.
Caveats: This implementation does not currently implement the common targets that other implementations do. There were several attempts to, but all ended in timing issues and boot inconsistencies during stress operations.
Enable chassis system power reset to allow removing power and restoring back.
The POST Complete GPIO is usually held asserted by BIOS after POST complete and de-asserts on reset. This de-assert behavior is currently used to detect warm resets.
Some systems are adding support for a PLT_RST eSPI signal that can be used to more accurately detect warm resets. When this option is enabled, x86-power-control will use PLT_RST to detect warm resets instead of POST Complete.
See https://github.com/Intel-BMC/host-misc-comm-manager for implementation example.