| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the OpenPower host firmware subsystem hostboot creates PELs, those
PELs get added to OpenBMC event logs in the ESEL entry of the
AdditionalData property. (Eventually hostboot will update their code to
use PLDM to send down PELs.)
This commit looks for that ESEL keyword on incoming event logs, extracts
the PEL data, and adds it to the PEL repository with all of the other
PELs.
It extracts the PEL data by converting the string value to a vector of
uint8_ts starting after the IPMI data fields contained in that string.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2b7f2915dceb9c306466b8181cae05a3ddd65057
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create a new event log/PEL when a PEL comes in from the host but it
isn't valid.
The PEL subsystem used is 'platform firmware' because the code won't
know which specific host subsystem it came from. The severity is
unrecoverable as opposed to informational to make it easier to notice.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I933e5c82f1ef755c6266604fbdec6d0c1fe5b784
|
|
|
|
|
|
|
|
|
| |
Create an event log (and a PEL) for the case when the host rejects a PEL
because it is malformed. This requires a new message registry entry for
the error.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ibd52921b5d6020f98b457b9ee0b3bb4f0b95e707
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are cases where the PEL code wants to be able to create OpenBMC
event logs (and thus PELs) for problems it encounters when trying to
create or import other PELs. For example, if the host were to send down
a malformed PEL, this code would like to create a new event log and
capture part of that bad PEL in the new PEL for debug purposes, as the
malformed PEL cannot be reported anywhere since it is malformed.
To handle this, create the EventLogger class that provides a log()
function that allows the PEL extension code to create OpenBMC event logs
(and thus PELs) from within.
The underlying function to do the event log creating is passed in via
the constructor so that it can be changed for testing.
The sd_event_add_defer function (wrapped by sdeventplus) is used to
dispatch the creation of a single event, so that the entry point is from
the event loop. If there are still events left on the queue after that,
then they will be also be scheduled with sd_event_add_defer so that the
events are always created from event loop calls.
EventLogger does not allow events to be added to the queue if it is
being done from within the creation function so that the code can't
get stuck in a loop of creating a new event every time an event is
created.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I6a9062074dc62cfb6043139ff0a9f3dfcd06c708
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For BMC created errors, look up the reason code in
the message registry for error description and also
meaning of data stored in hexwords 6-9 (if any).
Added registry message field in peltool list output.
"Primary SRC": {
"Section Version": "1",
"Sub-section type": "1",
"Created by": "0x1000",
"SRC Version": "0x02",
"SRC Format": "0x55",
"Power Control Net Fault": "False",
"Error Details": {
"Message": "PS 0x64 had a PGOOD Fault",
"PS_NUM": "0x64"
},
"Valid Word Count": "0x09",
"Reference Code": "BD8D1001",
"Hex Word 2": "00000055",
"Hex Word 3": "00000010",
"Hex Word 4": "00000000",
"Hex Word 5": "00000000",
"Hex Word 6": "00000064",
"Hex Word 7": "00000000",
"Hex Word 8": "00000000",
"Hex Word 9": "00000000"
}
"Primary SRC": {
"Section Version": "1",
"Sub-section type": "0",
"Created by": "0x4552",
"SRC Version": "0x02",
"SRC Format": "0x2008000",
"Power Control Net Fault": "False",
"Valid Word Count": "0x04",
"Reference Code": "B2001020",
"Hex Word 2": "02008000",
"Hex Word 3": "00000000",
"Hex Word 4": "00000012",
"Callout Section": {
"Callout Count": "1",
"Callouts": [{
"FRU Type": "Symbolic FRU",
"Priority": "Medium Priority",
"Part Number": "NEXTLVL"
}]
}
}
Testing: Manually run peltool and verified out. All unit tests passed.
Signed-off-by: Harisuddin Mohamed Isa <harisuddin@gmail.com>
Change-Id: I124627ba785413ebda02305b7d9f95431922e714
|
|
|
|
|
|
|
|
|
| |
To close the file descriptor returned from the getPEL D-Bus method call,
use the 'Defer' sdeventplus object to schedule it to happen from the
event loop.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2b850a1c92215e7f66166cc5440d7071663065c0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement the org.open_power.Logging.PEL D-Bus interface on
/xyz/openbmc_project/logging.
It provides the following methods:
* getPEL - Return a unix FD to the PEL data based on the PEL id.
* getPELFromOBMCID - Return PEL data in a vector based on the
corresponding OpenBMC event log id.
* hostAck - Called when the host has sent the PEL up to the OS,
which is the final step in the reporting process.
* hostReject - Called when the host has an issue with a PEL, either:
- The host doesn't have any more room for PELs at this moment.
- The PEL was malformed.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I633ae9e26d8336973363a1a207e8fd493f7ff7d2
|
|
|
|
|
|
|
|
|
| |
The PEL manager test wasn't creating the message registry
directory before writing into it, and seemed to have just
been lucking out that a previous test had created it.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I122242d65db02d8b80864c938cc28be434774304
|
|
|
|
|
| |
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I67c62ab5ac6e69ad0a84937834581f9a280a9167
|
|
|
|
|
|
|
|
|
|
|
|
| |
Look up incoming OpenBMC event logs in the message registry and create
PELs for them if a registry entry is found.
What happens when an event log can't be found in the message registry,
such as creating a different PEL, will be addressed in a separate
commit.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I45c634830021fdf2efb54e3cbfd6d496fd3d7d01
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit has no functional changes, it just does some things
to make the PEL data creator for testcases, pelDataFactory(), be
more manageable:
- Change to return a plain vector instead of a unique_ptr<vector>.
- Keeps the data for each section in separate vectors and then
either returns those as-is or combines them into a PEL.
- Change the TestPelType enum to TestPELType to match the style guide.
- Have pelDataFactory provide the SRC section instead of srcDataFactory.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I4770aa6a8169e89b6b8f685a9994d845c9e93cfe
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The message registry is a JSON file that holds data required to create a
PEL out of an OpenBMC event log. It includes fields like 'subsystem',
'event type', 'action flags', 'SRC reason code', etc.
Many fields in the message registry are optional, and a very minimal
entry make look like:
{
"Name": "xyz.openbmc_project.Power.Error.Fault",
"Subsystem": "power_supply",
"ActionFlags": ["service_action", "report"],
"SRC":
{
"ReasonCode": "0x2030"
}
}
This commit adds support to look up a message registry entry based on an
OpenBMC event log's 'Message' property (i.e.
xyz.openbmc_project.Power.Error.Fault) and then fill in a structure with
the fields found. Future commits will fill in the SRC related fields,
as well as actually create the PEL.
The message registry file can be found on the BMC at:
/usr/share/phosphor-logging/pels/message_registry.json.
For testing, users can put their own message_registry.json in
/etc/phosphor-logging, and that will take precedence.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ie4195ed7e58ab6a231271f6b295e63b1d0a4cd78
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are PEL fields that contain information that must be obtained from
various places throughout the BMC, such as the machine type/model/SN
from VPD, a few types of codes levels, etc.
Create a DataInterface class that will provide the APIs for collecting
this information. It has an abstract base class so that its functions
can be mocked to return specific data in test cases.
This commit provides APIs to read and present the machine type-model and
machine serial number. These will be used in the FailingMTM and
ExtendedUserHeader PEL sections.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Iec41fea8d9510ba711475154f019bd59f0028d2e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When someone deletes an OpenBMC event log, the corresponding PEL should
also be deleted. This commit adds support for that by keeping an
internal map of the IDs to the files that contain the PEL data in the
repository in order to find the file to remove. This will then get
called in the phosphor-logging extension's delete hook.
The actual map key is a structure of both the PEL ID and OpenBMC log ID,
so either can be used to find a PEL in the repository, which will be
useful in other cases, for example for retrieving PEL data based on the
PEL ID.
As the map needs to match the actual repository file contents, it will
get built on startup, and modified when PELs are added and removed.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I33bb96da297c770e175c5c6b19705dda1c8766b6
|
|
Create the Repository class that can save PELs in (and later retrieve
them from) the filesystem. It provides an add() method that can add
a PEL object to the repository.
Now, when the Manager class sees an OpenBMC event log created with the
RAWPEL metadata in the AdditionalData property that points at a file
that contains a PEL, it can save that PEL. Before the PEL is saved, the
log ID and commit timestamp fields in the PEL will be updated - the log
ID to a unique value, and the timestamp to the current time.
Change-Id: I8dbaddf0f155bcb6d40b933294ada83feb75ce53
|