- https://github.com/openbmc/phosphor-logging/blob/master/README.md
- https://github.com/openbmc/phosphor-logging/blob/master/extensions/openpower-pels/README.md
- https://github.com/openbmc/phosphor-logging/blob/master/extensions/openpower-pels/registry/README.md
- https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Common/Callout/README.md
- https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Logging/README.md
- https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Logging/Create.interface.yaml
- https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Logging/Entry.interface.yaml
- https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/org/open_power/Logging/PEL.interface.yaml
The old technique for creating an error log is to call the report() or commit() function in phosphor-logging/elog.hpp
These APIs require the error to be defined in YAML files. C++ code is generated based on the YAML that allows the error to be transmitted over D-Bus and converted into an error log. The YAML files are located in the phosphor-dbus-interfaces repository if it is a "common error" that could be logged by multiple repositories.
The new technique for creating error logs is to call a method on the xyz.openbmc_project.Logging.Create D-Bus interface. The interface is documented at https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Logging/Create.interface.yaml
The AdditionalData parameter on the interface can be used to identify callouts or store debug data.
Errors do not need to be defined in YAML files, making the process simpler and avoiding cross-repository dependencies.
Standard OpenBMC error logs are fairly light-weight and do not contain the same structure and fields as the PEL structure used on IBM enterprise systems.
The error logging repository has an extensions mechanism, allowing other error log formats to be supported. The PEL extension creates error logs that are similar to other IBM enterprise systems.
The PEL extension relies on a JSON file called the message registry. See https://github.com/openbmc/phosphor-logging/tree/master/extensions/openpower-pels/registry. This file contains additional information about an error, such as callouts and action flags. The message registry allows the PEL extension to create PELs based on standard BMC error logs.
The documentation referenced above describes the message registry fields in general. Below are some recommendations on how to specify the field values for errors in the phosphor-power repository.
This is a two byte hex value, like 0x2700. Where possible, the same value used on previous IBM enterprise systems will be specified.
These can be hard-coded in the message registry. However, they can also be specified dynamically using the AdditionalData parameter of the D-Bus create method.
See the message registry schema file for the list of valid choices. Many phosphor-power errors will use the "power" subsystem value.
The error severity can be hard-coded in the message registry. See the message registry schema file for the list of valid choices. However, the severity can also be specified dynamically using the Severity parameter of the D-Bus create method.
This contains a two-byte hex value that identifies the git repository that created the error. For the phosphor-power repository, the value is 0x2700. See https://github.com/openbmc/phosphor-logging/blob/master/extensions/openpower-pels/registry/ComponentIDs.md.
For phosphor-power errors use the value "11".
Currently these SRC words are not used for phosphor-power errors. The field value can be an empty array in the message registry.
This should only be set to true for power-related errors that are so severe that they cause a running system to power down.
These contain the human readable description of the error. They will appear in the output of the PEL parser tool and potentially in Redfish output. There are currently no standards on what these fields should contain. Setting them both to the same string value is the recommended approach for now.