commit | 31c45f60d65117891d41cb5b1caeb02a7e44f0ef | [log] [tgz] |
---|---|---|
author | Arun P. Mohanan <arun.p.m@linux.intel.com> | Mon Oct 18 21:52:39 2021 +0530 |
committer | Arun P. Mohanan <arun.p.m@linux.intel.com> | Tue Oct 19 08:23:18 2021 +0530 |
tree | 331ab9b9da557362d56a5d13cbc2c04f6ac9d8ba | |
parent | d4b74b4f7ccc92152eabf7eebb5f1722889a73c9 [diff] |
Separately handle RestrictionMode & POSTComplete Having single try catch to get 2 separate D-Bus properties from different services resulted in incorrect value for 2nd property. In the previous implementation, when `RestrictionModeService` is not initialized it will throw and return. In this case it was missing to read the `OperatingSystemState` property and it was defaulting postComplete as true but actually it can be false. The above case resulted in a a situation where BMC blocked the IPMI commands(Over KCS trust policy- DenyAll & Whitelist ) over KCS channel even before BIOS completes booting. As a result BIOS never get response for IPMI commands like getDeviceID(In DenyAll mode) and caused further issues. Separate out these into seperate try catch to avoid above issue. Also updated the function to use getDbusProperty() API. Tested: Verified postComplete value is getting cached correctly even if the restrictionModeService is not up and running. Signed-off-by: Arun P. Mohanan <arun.p.m@linux.intel.com> Change-Id: I394a7c46703e917b0075da6cc5469de1b66a9b7a
This component is intended to provide Intel-specific IPMI[3]
command handlers for OpenBMC. These handlers are intended to integrate BMC with servers based on Intel architecture.
intel-ipmi-oem
serves as an extension[1]
to OpenBMC IPMI daemon[2]
. It is compiled as a shared library and intended to both:
Related features provided by the library are grouped in separate source files. Main extensions to vanilla OpenBMC IPMI stack are the following:
[4]