| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating a new PEL, add a UserData section that contains various
pieces of system information that will be saved in every error log.
In this first commit, just save the process name of the creator,
provided they passed in the '_PID' AdditionalData item containing their
PID.
Future commits will add other items like certain D-Bus properties.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I7139b4056e494277ff3388bfa8a00002c9c89dc1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
While not really likely, it is technically possible that the
AdditionalData property in an event log is large enough that saving it
into a UserData section could make the PEL exceed its maximum size of
16KB. To guard against this, check that an overflow wouldn't occur
before saving that section in the PEL.
In future commits, other UserData sections will be added where this
check will also be needed.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Iac312a24b1d445e93de5a09f35a43d940571a3f8
|
| |
|
|
|
|
|
|
|
|
|
| |
Add a size() function to the PEL class that adds up the size fields
in the header of every PEL section.
This required a fix to some testcases where the size field was wrong in
a header.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I0d70deae116cd3835f2c0ab34e13811da471fb14
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Override the getJSON() function in the UserData section so it will
support peltool pretty printing when the data has been stored as JSON
(component phosphor-logging, subtype 1 as defined in
user_data_formats.hpp).
It first converts the original JSON string to a nlohmann::json object to
validate it is valid JSON and then uses nlohmann::json's stream <<
operator to convert it into a pretty string.
This also sets up a framework where other UserData parsing functions can
be called from, and it is all only compiled into peltool, and not into
phosphor-log-manager.
The UserData section created out of the OpenBMC event log's
AdditionalData property already makes use of this format.
Here are some example outputs. Note that the 'Data' key is added by
this code for JSON that isn't already an object (dict) to make it one.
"User Data": {
"OPERATION": "something",
"REGISTER_FFDC": "REG1=0x8|REG2=0x9|REG3=0x55",
"RETURN_VALUE": "-12",
"TIMEOUT_IN_MSEC": "100",
"_PID": "993"
},
"User Data": {
"Data": [
"OPERATION",
"REGISTER_FFDC",
"RETURN_VALUE",
"TIMEOUT_IN_MSEC",
"_PID"
]
},
"User Data": {
"Data": "This is a string"
}
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I7b034ac24339b5b019db3b57d8e71cb03559363e
|
| |
|
|
|
|
|
|
|
|
| |
So far, the states are new, sent, and acked.
Also added PEL object access to getting and setting these on the User
Header section object.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I0dfb2d1a39fe69b2a47bf7d461f08e92039a3e03
|
| |
|
|
|
|
|
|
| |
This includes making the flatten() method const in the PEL section base
class and in all of its derived classes.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I6be787962c6d7dfa01bdced2f9024564e6ac1b08
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the PEL spec, the Action Flags and Event Type fields in the
User Header section must be in agreement with the Severity field. So,
when a PEL is being created from an OpenBMC event log, check those
values for correctness and fix them up if required.
In addition, as those fields are optional in the message registry, this
code will also just set these two fields to valid values if they were
left out.
The rules being followed are documented in the PEL readme.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Iad88de5080ba79a9ff31f962ef99bfc11994b9ed
|
| |
|
|
|
|
|
|
|
| |
PELTooL application would be used to interact with PELs. This commit has
the first functionality, where a PEL file is passed and all PEL sections
are hexdumped in a JSON object.
Signed-off-by: Aatir <aatrapps@gmail.com>
Change-Id: I155d75bb58cbd14a297b094314f7fd1f271f4f37
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the combined non-const accessor/setter functions for the
PrivateHeader and UserHeader fields to the standard const accessors, and
have separate setters for the fields that need to be modified.
In addition, make the 'get PrivateHeader' and 'get UserHeader' functions
on the PEL class return a const reference.
This allows const enforcement on the PEL class, for things like:
void func(const PEL& pel)
{
auto id = pel.privateHeader().id();
}
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I840170e72b41e9e2465f716617500269244de6d9
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Save the contents of the AdditionalData OpenBMC event log property as
JSON in a UserData PEL section.
For example, if the AdditionalData property, which is an array of
strings, looks like:
["KEY1=VALUE1", "KEY=VALUE2"]
Then the data stored as ASCII text in the UserData section is:
{"KEY1":"VALUE1","KEY2":"VALUE2"}
If one of the keys is "ESEL", then that entry is removed from the
UserData output as that contains a full raw PEL from the host sent down
as ASCII text.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ia6ffabb39fdb4315ec2152744414e44f7d2ec4aa
|
| |
|
|
|
|
|
|
|
| |
When a PEL is created from an OpenBMC event log, add the FailingMTMS
section to the PEL. This contains the machine type, model, and serial
number fields.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I8d08e6dda00260efebd2c6ac165270d2aaf98d67
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the ability to create an SRC PEL section based on the message
registry entry for an OpenBMC event log.
The event log's AdditionalData property is used as a source for the user
defined data words of the SRC, while the other fields in the SRC's data
words are filled in either from the message registry fields or from
current system state or configuration.
The ASCII string field of the SRC is filled in based on the message
registry entry.
This commit doesn't fill in every system status field, as many aren't
even available anywhere yet. Also, this commit doesn't support adding
callouts to an SRC, that will also be handled in the future.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I67fe44e07e4eda6bdeedb4af2eacfc197deb6eb3
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the Generic section object has been introduced so there are
objects for every section, a flatten can be done by flattening every
object inside the PEL and the previous workaround to save the original
raw data can be removed.
This also adds a test case that uses a real PEL from a previous
generation of systems to flatten to give some better coverage than just
using hand coded PEL sections.
A side affect of this is that the PEL constructors that take the raw
data cannot take a const vector of data, as the Stream class that will
be used to read from the vector cannot take a const. Testcases have
been updated to ensure this data is not modified.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I64ae1d1d4a742c80e14666d6b2a6e1e0efd5fd62
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When unflattening a PEL, create objects for every PEL section in the
log. It will use a factory method to choose which object type to create
based on the section ID in the section header. All of these object will
go into a vector of Section objects, which is the base class for every
PEL section class.
The factory will default to creating a Generic object when it doesn't
have any other type to create.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ief0e4df5c586a46cea66ca47b4479e3444815309
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a constructor to the PEL class so it can be built from the message
registry entry for that error along with the event log properties.
When support for new sections are added, they will be created here as
well along with the PrivateHeader and UserHeader section classes.
Eventually, this constructor will be called from the Manager class after
it is told a new event log has been created and after it looks up that
error's PEL message registry entry.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2d8ca550736aab45a30ac3db9861723b33e6cd32
|
|
|
This class represents a Platform Event Log.
A PEL consists of sections, and this commit just adds support for the
only required sections - the Private Header and User Header, by
including those specific objects. More will be added in the future.
The only constructor provided in this commit is to construct the object
from an existing flattened PEL buffer. This is for use in the case when
a PEL is received from off the BMC, such as from the host. Future
commits will add support for creating PELs from OpenBMC event logs.
Since there aren't objects yet for every PEL section, the class cannot
make a full flattened PEL without still keeping around the original PEL
data it received in the constructor as mentioned above. So for now it
will keep that data and just overlay the sections it does support when
flattening. In the future, a fully formed PEL will be able to be
constructed from just flattening the section objects in the correct
order.
This commit provides a few public methods of note:
* data() - returns a flattened PEL
* assignID() - sets a unique ID in the log ID field in the Private
Header
* setCommitTime() - Sets the commit timestamp in the Private Header
to the current time
* valid() - Says if the PEL is properly formed
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2a9d82df9cd096ce77ecca7b2f73b097b8368aa2
|
