| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the xyz.openbmc_project.Common.Error.* errors from
xyz/openbmc_project/Common.errors.yaml file in the
phosphor-dbus-interfaces repository.
It is possible that errors defined in these YAML files never have event
logs created out of them, but instead are intended to just be returned
on failed D-Bus operations, such as a method failure. Aside from
searching the whole OpenBMC code base there is no way to know, so just
define PELs for all of them to be safe.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I00ce1e9423c2b260f78d2d3d0aa8a495c3b13504
|
|
|
|
|
|
|
|
|
| |
As phosphor-log-manager and peltool share source files, create libpel.la
to contain those common files that will then be included by both of
them.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ie3882d1b0929bace10ae638a8762e2b804e594c7
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Action Flags bits in the PEL need to be in agreement with other PEL
fields, such as if the severity is informational then the 'report' flag
cannot be on. In fact, for most logs all of these flags can be deduced
from the other PEL fields.
So, to avoid the case of the action flags in the registry not matching
the other PEL fields, make them optional and the BMC code will set them
appropriately. And when they are specified, the BMC code will still run
through the same code to ensure everything is in agreement.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I5bea83d01846d7a2d3307666e6d0758a99229e3f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a for_each() function to the PEL repository that takes a user
defined function that will be run on every PEL, unless that function
says to stop early.
The user defined function is a std::function<bool>(const PEL&);
For example, to save up to 100 IDs in the repo into a vector:
std::vector<uint32_t> ids;
ForEachFunc f = [&ids](const PEL& pel) {
ids.push_back(pel.id());
return ids.size() == 100 ? true : false;
};
repo.for_each(f);
This will be used to find which PELs still need to be sent up to the
host after a reboot, among other things.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ic60525a8ab3dd593ba37e43a6cb0b3db8dda7cee
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
It doesn't modify the object, so can be const.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ib3bbe2b8467578b0cddce0284aa6ae95f1ad826a
|
|
|
|
|
|
|
|
| |
Make the flatten functions const for the various classes
that represent the SRC substructures.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I08f4ae6de65e269c9f1b82315115969c8552c782
|
|
|
|
|
|
|
|
| |
Future commits will eventually make every flatten function const, as
they should be since flattening an object should not affect it.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I285963805800b29163c5a3979a33590f64c03d00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I67c62ab5ac6e69ad0a84937834581f9a280a9167
|
|
|
|
|
| |
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I31b12f509d32b79064a8a427af35e6a310273051
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Move them to a header file so other files can use them in the future.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Icb604489e9629724a79d2fc8b110e461b6aa6e01
|
|
|
|
|
|
|
|
| |
A future commit will fill in the field if it isn't
present.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I67371433162ce2198a362796d274695a1bd6a6dc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Add a section in the PEL README to document the UserData sections
that will be created in every new PEL.
Change-Id: I9ff9a69f1d22b56aa8bb9d559802d0595d787c0a
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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
|
|
|
|
|
|
|
|
|
| |
Reason codes must be unique for every error until there is a
specific reason for them not to be, so check for that while
validating the message registry JSON file.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I74e0e24e1f129ebf94d25aaf5200b30b256b1307
|
|
|
|
|
|
|
|
| |
This script will check the JSON against the schema, as well as do a few
other checks that can't be encoded into a schema.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I97c0fc0f69baac3c076b557b67e47ce8abfccf36
|
|
|
|
|
|
|
|
|
|
|
| |
This README describes the message registry in an easier to read way than
what is buried in the JSON schema.
The commit also provides a file to document which component IDs are
used by which repositories/applications.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ibf1109e0a1fb6fff872cfa91d79c007ecf5527b0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The message registry is JSON data that will aid in converting OpenBMC
event logs into IBM's Platform Event Log (PEL) format. PELs have more
fields than event logs, many with specific IBM defined values, that need
to be able to be looked up for an OpenBMC event log so the PEL can be
filled in. In addition to aiding in creating PELs, it also contains
information to aid in parsing PELs.
This schema defines how that JSON will look, and this commit also
contains an example registry file.
A script will be added in the future to validate the registry JSON
against the schema during a bitbake build.
Until there is a need, the message registry will be contained in a
single JSON file. If there is a need, it can be split up along some
predetermined rules in the future.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I98620b263bd1faff27e36da7a0c101a982b58057
|
|
|
|
|
|
|
|
|
| |
This will eventually contain the information to create PELs out of
OpenBMC event logs. It is installed into
/usr/share/phosphor-logging/pels.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Iaf67881890a47f605af3ae69b54f186b63915ca6
|
|
|
|
|
|
|
|
|
|
| |
Enable the default contructor so that an object can be created
without needing any data.
Also make getValue() const as it is const.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Id81879e0367edb1055cbf848ed738bc8dd86e953
|
|
|
|
|
|
|
| |
The values are all supposed to be in hex.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ic1af46a3505f0f77d6f6f0f1bff998f2ab527522
|
|
|
|
|
|
|
|
|
| |
There was no need for the stream insertion operator, <<,
to take a uint8_t, char, uin16_t, uint32_t, or uint64_t as
a reference as they are small and they aren't being modified.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I9fbf28af7fa6e8e73fd2df8c102e1689647e686d
|
|
|
|
|
|
|
|
| |
Check the SRC ASCII string, and also check the full ID of the last
section object.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ie5b5ef3783d316a31e370ef898e11ecaf16b9551
|
|
|
|
|
|
|
|
|
| |
Several testcases use pelDataFactory() for their PEL data. Add SRC,
FailingMTMS, and UserData sections to this data to get some better
coverage.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2b09fc94c32df1a6fd5bd3cb96c98dc7c3bcc1f2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the stream constructor, initialize the member variables to 0 before
unflattening.
This only matters when the data is so short that the 'section count'
field doesn't get initialized and so the code tries to loop through and
unflatten that many optional sections, and since there aren't actually
any it was spitting out extra journal traces about invalid section IDs.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: If08e9ae244d5ade96cafa2160ad9714bebe34551
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This section consists of:
- An 8B header
- 8 4B words of hex data
- Some data is predefined based on the SRC format, some is free format.
- A 32B ASCII character string (The AsciiString class)
- An optional section for FRU callouts (The Callouts class)
Usually, the term SRC (System Reference Code) refers to the contents of
the ASCII string and the hex data words, which can then be looked up in
service documentation to find the meaning of the event log. This PEL
section wraps this pure SRC with additional data like callouts.
This commit only adds support for unflattening the section from an
existing PEL, and flattening it again. Future commits will add support
for creating an SRC from message registry data.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I3dd97c6aca59cc6d6d6fadef84465164090d5658
|
|
|
|
|
|
|
|
|
|
|
|
| |
This Callouts class represents the optional subsection of an SRC PEL
section that contains FRU callouts. It is only present in the SRC when
there are callouts, and it comes at the end of the section.
It is basically just a container for the Callout objects that represent
the actual callouts.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I1d4d95b82f9b4943728d7939e3bf89e4a7bcbb75
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class represents a single FRU callout in the SRC section of a PEL.
When there are multiple callouts, there will be multiple instances of
this class created. Technically, the callout isn't always a FRU, such
as it could be a maintenance procedure name, but the spec still refers
to this section as the FRU callout section.
The callout priority and location code are in this structure.
There can also be up to one each of three types of substructures
in a single callout:
* FRU Identity (must be first if present)
* Power Controlling Enclosure (PCE)
* Manufacturing Replaceable Unit (MRU)
This commit just provides support for creating this object from a
flattened PEL, such as one that comes down from the host. A future
commit will add support for creating a callout for BMC created event
logs.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I49535285e3cbaa15dfe031648cfaf262380a1cf7
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This substructure is part of the callout subsection in the SRC section
of a PEL, and contains information about Manufacturing Replaceable Units
(MRUs). MRUs are components on a parent FRU (Field Replaceable Unit)
that may be able to be replaced in a manufacturing environment, hence
the name.
This substructure includes a list of <priority, MRU ID> pairs, where the
priority is the same priority value type as used elsewhere in the SRC
section ('H', 'M', 'L', etc), and the MRU ID is a 4B ID that development
will tell manufacturing the meanings of.
This commit only adds support for creating an object from a flattened PEL,
such as one that comes down from the host. A future commit will handle
creating it from scratch for BMC errors.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I6352e1a3cb84db0516902786faca4c387afef411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This substructure is part of the callout subsection in the SRC section
of a PEL, and contains enclosure information for when another enclosure
controls the power of the failing entity. This would be an unusual
case, when the piece of hardware that is being called out has its power
controlled by another enclosure, for example when an I/O expansion
drawer is connected to 2 servers, and only one of them controls its
power.
This includes:
* The enclosure's name
* The enclosure's machine type, model, and serial number
The BMC will never create this section for BMC errors, but it may need
to unflatten them for PELs sent down from a host that has to deal with
I/O drawers.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ie04c1ee3fdfa67ee8666c10fa3bc837f4d33a9ef
|
|
|
|
|
|
|
|
| |
Add << and >> operators to the Stream class for use with a
std::vector<char>.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I22a08bb6518f9aed2385bcdce446a67ea9ea386d
|
|
|
|
|
|
|
|
| |
This class is used by a few other classes, so make it easier to get
data out of it.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2feb4b83a09e6cb6056c9f1a903ca55e8cacf2ae
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This substructure is part of the callout subsection in the SRC
section of a PEL, and contains information about the FRU (Field
Replaceable Unit) being called out.
This includes:
* The specific type of FRU (see the flags field definitions)
* The FRU part number
* The FRU CCIN value (CCIN = a keyword in VPD).
* The FRU serial number
Instead of just calling out a FRU, this structure can instead be used to
call out a maintenance procedure, which is a string that is used as
a key into the service documentation that maps to a procedure to fix
the problem.
This commit only adds support for creating an object from a flattened PEL,
such as one that comes down from the host. A future commit will handle
creating it from scratch for BMC errors.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ic2b9489abea48084116bf2f450bd293c2d655979
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the SRC section of a PEL, there is a field called the 'ASCII string'.
This is the string of 32 characters that shows up on the panel when the
SRC function is chosen, and usually when people refer to an SRC, the
first 8 characters of this field is what they are referring to.
This new class handles that string. It will belong to the SRC section
object.
For BMC error SRCs, it looks like: BDSSRRRR
Where:
BD = "BD", indicating a BMC error SRC
SS = subsystem value from PEL spec
RRRR = reason code of the error
The remaining 24 characters are spaces (' ').
For example:
"BD8D1234 "
For BMC power* related errors, the value is:
"11001234 "
Where the difference is the "11" instead of "BD", and the following
2 bytes are always "00".
* 'power' means comes from the repository that monitors for power
faults. This is different purely to help keep field service
documentation the same as in previous IBM server generations.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I6e7292e7f5b501428999781b1a5ee5c243a63ac6
|
|
|
|
|
|
|
|
|
|
| |
object-mapper.md is moving under architecture/ as part of
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/26250/
26250 should merge before this is merged.
Change-Id: I4b6d06cd308bae8ebce0ba9ca3c84273e3283a42
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This class is used for accessing the UserData section of a PEL.
This section contains free format data that can be identified by the
component ID, subtype, and version fields in the section header.
Signed-off-by: Aatir Manzur <aatrapps@gmail.com>
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I1223f84353e81202d1ff63c00f3d926cda4994e5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This object will be created when unflattening a PEL when there is no
other class to use for that section. It just contains a vector<uint8_t>
for its data.
This is done so that the code can always have objects for all PEL
sections, which helps in validating (can at least ensure every section
has a valid header and size), printing (will always have an object to
get its data to at least hex dump), and re-flattening (no need to keep
around the original data buffer).
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2b79feb4abc0f44179bdb8eab950f0d274e4e472
|
|
|
|
|
|
|
|
| |
Add << and >> operators to the Stream class for use with a
std::vector<uint8_t>.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I9656ee4e34840d311148e6a701131b3420e62d25
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
Add a constructor to the UserHeader section class so it can be built
from the message registry entry for that error along with the event log
severity.
This will be used when creating PELs from OpenBMC event logs.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I7e432f59de7b3f0ba77c3e5887ed5ec3f442ed44
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a function to map the OpenBMC event log severity values to PEL
severity values.
When creating a PEL from an OpenBMC event log, the event log will have
its own severity property, and if the PEL message registry entry for
that error doesn't supply its own severity (it's optional), use this
function to come up with the PEL severity value to use.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I66aa001265d8acadb165de874e4ade03a8e28007
|