PEL: Activate service indicators on new PEL

A service indicator is a device used to add the user during system
service actions. In the case of PELs, service indicators are always
LEDs.

When a new

PEL: Activate service indicators on new PEL

A service indicator is a device used to add the user during system
service actions. In the case of PELs, service indicators are always
LEDs.

When a new PEL is created or received from the host, code will check the
service indicator policy to see if any indicators need to be set at that
time based on the PEL callouts.

There is a specific policy named LightPath that is the default, and it
is currently the only supported policy. This policy has a set of rules
to say which called out location codes need their indicators activated.

After it determines the location codes, it looks up the corresponding
D-Bus inventory paths for them, and then looks up the LED group objects
to assert based on those inventory paths.

If, for any reason, the code can't get a complete list of FRU LEDs to
turn on, then it will turn on the System Attention Indicator LED. It is
still TBD how that is actually done.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I771258a8957fb0944ec1f8787086123e068bc6cc

show more ...

PEL: Add callouts to pelFactory()'s test PEL

Add a hardware callout to the PEL that gets returned from pelFactory()
in unit test.

This brings the size up to between 400 and 500 so there is also a
t

PEL: Add callouts to pelFactory()'s test PEL

Add a hardware callout to the PEL that gets returned from pelFactory()
in unit test.

This brings the size up to between 400 and 500 so there is also a
testcase update that needs to be made so it doesn't assert.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I64e9ee99c4bae7c804b1c559b8f2f59f6ad828fc

show more ...

PEL: Update getInventoryFromLocCode

Add an argument to this function that says if the location code passed
in is already expanded (has the fcs and mts placeholders filled in with
VPD data).

This wi

PEL: Update getInventoryFromLocCode

Add an argument to this function that says if the location code passed
in is already expanded (has the fcs and mts placeholders filled in with
VPD data).

This will be used in an upcoming commit that pulls location codes out of
PEL callouts.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Icefa9475962bdf161ddb8b51ce3dab805bcd396b

show more ...

PEL: Trace BMC log ID on new PEL, and use fmt

In addition to tracing the PEL ID in the journal when a new PEL is
created, also trace the corresponding OpenBMC event log ID.

Use the fmt library to h

PEL: Trace BMC log ID on new PEL, and use fmt

In addition to tracing the PEL ID in the journal when a new PEL is
created, also trace the corresponding OpenBMC event log ID.

Use the fmt library to help with the string formatting as things were
getting out of hand without it.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I3f7e43f2ed39ff1d1d6a65d0412e3a8c82a86b26

show more ...

PEL: Still create PEL when error not in registry

When an OpenBMC event log is created for an error that isn't in the PEL
message registry, the code will now find a registry entry using another
defau

PEL: Still create PEL when error not in registry

When an OpenBMC event log is created for an error that isn't in the PEL
message registry, the code will now find a registry entry using another
default error name. This default PEL will contain the severity and any
callouts specified by the original event log, and its message used by
peltool and possibly Redfish will state that the actual meaning for the
error is unknown.

The error name property that was missing from the registry will be
placed in the JSON UserData section that hold the AdditionalData
property fields under the key ERROR_NAME.

Doing this allows one to see all errors on a system just by looking at
PELs, and not miss important ones just because a developer doesn't have
their error in the registry yet.

When these are seen, it may be a good idea to create bug reports as a
reminder that the missing error needs to be added.

Change-Id: Ifa3db21af96745dd651da5f5af0ab970a952f46a

show more ...

PEL: Support a default device callouts file

Normally, the device callouts code, which finds the callouts to use for
FRUs along a specific device path, will look for a JSON file to use by
looping thr

PEL: Support a default device callouts file

Normally, the device callouts code, which finds the callouts to use for
FRUs along a specific device path, will look for a JSON file to use by
looping through the list of compatible system names and adding
'_dev_callouts.json' to the name.

However at this point in time, the code that is supposed to populate
that list isn't done yet, so it will always be empty. In order to still
be able find a file, have it look for a default file called just
_dev_callouts.json after it tries and fails to find one based on system
name.

This file will be installed into the flash image from a bitbake recipe,
and eventually when that list of names field is populated, it can be
renamed in the recipe without having to make a code change here.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I39e9dbb3e921eb5e5be30717a277b07febd2de55

show more ...

PEL: Watch for manually deleted PEL files

Currently, if someone were to manually delete a PEL file, the Repository
class would not know to remove it from its _pelAttributes index which
will lead to

PEL: Watch for manually deleted PEL files

Currently, if someone were to manually delete a PEL file, the Repository
class would not know to remove it from its _pelAttributes index which
will lead to problems down the line.

To fix this, create an inotify watch that looks for files to be deleted
in the PEL directory. When one or more is deleted, remove it from the
Repository class and also remove the OpenBMC event log for it.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I238c0b886b01e88cc931162a0596b848d1d975b1

show more ...

PEL: On remove() call, return the removed LogID

Have Repository::remove(const LogID& id), which is used to remove
a PEL, return the full LogID of the removed PEL instead of not
returning anything.

PEL: On remove() call, return the removed LogID

Have Repository::remove(const LogID& id), which is used to remove
a PEL, return the full LogID of the removed PEL instead of not
returning anything.

That input id only has to have a filled in PEL ID or OpenBMC event log
ID field, but not both, so returning the full LogID of the removed PEL
ensure the calling code will have both values.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: If869c59acd59563db137d7c9523210539b51a040

show more ...

PEL: Check if PEL pruning necessary on a new PEL

When a new PEL is added check if the size of all PELs is now more than
95% of the maximum capacity. If it is, call the repository's prune()
function

PEL: Check if PEL pruning necessary on a new PEL

When a new PEL is added check if the size of all PELs is now more than
95% of the maximum capacity. If it is, call the repository's prune()
function from the event loop to make more space. Also delete the
OpenBMC event logs corresponding to the PELs that were just deleted.

It's called from the event loop so that the current D-Bus method
response that the code is in now can return to the caller first.

It tops out at 95% to ensure that we never go over. It's possible this
can be tuned in the future, but at the current 20MB limit that still
allows 19MB before pruning will take it down to at most 18MB.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I962866eceee89cd605fcd36ec08b20ff762fe6cd

show more ...

PEL: Implement respository pruning

This adds a prune() public method on the Repository class to remove PELs
down to at most 90% of capacity and then down to 80% of the maximum
number of PELs if ther

PEL: Implement respository pruning

This adds a prune() public method on the Repository class to remove PELs
down to at most 90% of capacity and then down to 80% of the maximum
number of PELs if there were more than the maximum.

It does the first set of pruning by placing each PEL is one of 4
categories, and then reducing the total size of each category. The
categories are:
* BMC informational PELs - reduced to 15% of max
* BMC non-informational PELs - reduced to 30% of max
* non-BMC informational PELs - reduced to 15% of max
* non-BMC non-informational PELs - reduced to 30% of max

Within each category, PELs are removed oldest first, and also 4 passes
are made through the PELs, only removing PELs that meet a specific
requirement each pass, stopping as soon as the category limit is
reached.

The pass requirements are:
* Pass 1: Only remove HMC acked PELs
* Pass 2: Only remove OS acked PELs
* Pass 3: Only remove host sent PELs
* Pass 4: Remove any PEL

After the 4 passes on the 4 categories are done then the number of PELs
remaining is checked against the maximum number. If it is more than the
maximum, it will remove the PELs down to 80% of that limit using the
same 4 passes as above. This is done to keep the number of PELs down to
a manageable number when there are a lot of small PELs that don't engage
the size based pruning.

The pruning code doesn't just bring the size or number of PELs to just
below their limit, but rather a percentage below, so that it won't get
into a situation where the algorithm has to run on the repository every
single time a PEL is added.

The OpenBMC event log corresponding to the PELs are not removed. That
is left to other code.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I24da611c095fd3b22b6b1ffab52d919cac5f68b4

show more ...

PEL: Keep size statistics of PEL repo

Keep a running total of several size statistics of the PEL repository.

The statistics are:
* Total size of all PELs
* Total size of BMC created PELs
* Total si

PEL: Keep size statistics of PEL repo

Keep a running total of several size statistics of the PEL repository.

The statistics are:
* Total size of all PELs
* Total size of BMC created PELs
* Total size of BMC created informational PELs
* Total size of BMC created non-informational PELs
* Total size of non-BMC created PELs
* Total size of non-BMC created informational PELs
* Total size of non-BMC created non-informational PELs

Here, size refers to the disk size the PEL uses, which is different than
the file size. The disk size is retrieved from the stat() function and
is the number of 512B blocks used.

The term 'informational' above doesn't strictly refer to the
informational severity value (0x0), but also includes other cases, such
as hidden recovered PELs.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I07a3ccd7cfe802a344a2db47daba5fb05d56489f

show more ...

PEL: Create a PEL that takes parameters for test

Make a pelFactory() function that unit tests can use where the caller
can specify the following attributes:
* ID (PLID also set to this. BMC log ID

PEL: Create a PEL that takes parameters for test

Make a pelFactory() function that unit tests can use where the caller
can specify the following attributes:
* ID (PLID also set to this. BMC log ID = ID + 500)
* Creator ID
* Severity
* Action Flags
* PEL Size

The desired size is reached by adding a UserData section as the last
section.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I99add4c17a352030298874340f8bf9d8041a3e74

show more ...

PEL: Add PEL repository capping related fields

If not capped, the PEL repository would keep taking up more and more
space as more PELs are added. In preparation for handling this, add
a field to th

PEL: Add PEL repository capping related fields

If not capped, the PEL repository would keep taking up more and more
space as more PELs are added. In preparation for handling this, add
a field to the Repository class to track the total size that all PELs can
take up and a field to track the maximum number of PELs that can be
stored.

The size value is hardcoded to be 20MB (and 100KB in unit test), though
a Repository class constructor allows the number to use to be passed in.
The max number of PELs field is hardcoded to 3000 (100 in test) and this
can also be changed in the constructor.

In the future if different systems or configurations require different
values, then this could be set at configure time. This isn't done now
because I want to only add PEL options to the common phosphor-logging
configure.ac if absolutely necessary as the majority of phosphor-logging
users don't use PELs.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I72609a727229f96bd8ac23a630f25fd8b5c73427

show more ...

Support reading VERSION_ID without quotes

The VERSION_ID value in /etc/os-release recently had its surrounding
quotation marks removed. Update the code to be able to read values out
of /etc/os-rele

Support reading VERSION_ID without quotes

The VERSION_ID value in /etc/os-release recently had its surrounding
quotation marks removed. Update the code to be able to read values out
of /etc/os-release either with or without quotes, and make it a utility
function so that it can be used in multiple places.

Props to the phosphor-bmc-code-mgmt repo for the elegant implementation.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I348625ba49214ab2977d9e70a4337299bef5ed3a

Change-Id: I9d201954a8116dfda32d096a347e150d93fbfb46

show more ...

PEL: Add PEL testcase for device callouts

Add a PEL class unit test where device callouts are included in the PEL.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I22567c29c7e2a8dd0a024

PEL: Add PEL testcase for device callouts

Add a PEL class unit test where device callouts are included in the PEL.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I22567c29c7e2a8dd0a024a459756ee2cde8239fb

show more ...

PEL: Add device path callouts in SRC section

When the SRC section is created and it has either CALLOUT_DEVICE_PATH or
(CALLOUT_IIC_BUS, CALLOUT_IIC_ADDR) in the AdditionalData property, look
up the

PEL: Add device path callouts in SRC section

When the SRC section is created and it has either CALLOUT_DEVICE_PATH or
(CALLOUT_IIC_BUS, CALLOUT_IIC_ADDR) in the AdditionalData property, look
up the device callouts to add to the section using
device_callouts::getCallouts().

CALLOUT_IIC_BUS can either be the plain bus number, like "5", or a /dev
path like "/dev/i2c-5". CALLOUT_IIC_ADDR is a 7 bit I2C address and can
either be in decimal, like "16", or in hex like "0x10".

For now, it just stores any MRUs that come back in the section debug
data that will be added to a UserData section.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I33ae6a3dbc75e2892b29f37cfac414ca9747a2f9

show more ...

PEL: Generate HW callouts from the msg registry

Callouts that aren't procedures or symbolic FRUs can be defined in the
message registry. Fill in the SRC code that creates these hardware
callout obj

PEL: Generate HW callouts from the msg registry

Callouts that aren't procedures or symbolic FRUs can be defined in the
message registry. Fill in the SRC code that creates these hardware
callout objects in this case.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I610c6c58b8672da283722c1d68b6dfdf28e480e3

show more ...

PEL: Add location code related stubs

Add 2 location code related API stubs to DataInterface:
* expandLocationCode - Fills in the 'Ufcs' template with the actual
feature code a

PEL: Add location code related stubs

Add 2 location code related API stubs to DataInterface:
* expandLocationCode - Fills in the 'Ufcs' template with the actual
feature code and SN.
* getInventoryFromLocCode - Returns the inventory D-Bus object path
that that location code represents.

These will eventually wrap D-Bus method calls to the VPD daemon when
that gets implemented. In the meantime, these can't return
valid data on real hardware but they can be mocked to do so.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I955d8bac626d45ffbed63c29c497ad0db37d9b21

show more ...

PEL: devcallouts: Get callouts from the JSON

Using the functions that extract search keys from the device path, look
up the callouts in the appriopriate JSON entry and return them as a
vector of Cal

PEL: devcallouts: Get callouts from the JSON

Using the functions that extract search keys from the device path, look
up the callouts in the appriopriate JSON entry and return them as a
vector of Callout objects.

The first callout will have the 'debug' field filled in with the search
keys used and the MRW target name of the destination device. In the
future this will be added into a UserData section of a PEL with these
callouts to make debugging easier - i.e. making it easier to know what
device it was that failed when looking at the PEL.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ic4df1ce95fbc5ed277b43a1ffca08ce477d5f8c6

show more ...

PEL: devcallouts: Extract search keys

In order to find the callouts for a device path, the search keys need to
be pulled out of the device path.

The keys are:
* I2C - bus and address
* FSI - link n

PEL: devcallouts: Extract search keys

In order to find the callouts for a device path, the search keys need to
be pulled out of the device path.

The keys are:
* I2C - bus and address
* FSI - link numbers
- Multiple link hops separated by dashes like "0-1"
* SPI - bus
* FSI-I2C - link numbers and I2C bus and address
* FSI-SPI - link numbers and SPI bus number

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I1f8bf975fb34a61ea3fa2ac5b397afdc73cd799b

show more ...

PEL: devcallouts: Determine access type

Add a function to determine if the device path represents an I2C, FSI,
FSI-I2C, or FSI-SPI attached device.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>

PEL: devcallouts: Determine access type

Add a function to determine if the device path represents an I2C, FSI,
FSI-I2C, or FSI-SPI attached device.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ie58452e7988938e9b701357bbb96252be971902f

show more ...

PEL: Add APIs to look up device path callouts

This commit adds the interfaces device_callouts::getCallouts() and
device_callouts::getI2CCallouts() that will be used to look up the FRU
callouts to ad

PEL: Add APIs to look up device path callouts

This commit adds the interfaces device_callouts::getCallouts() and
device_callouts::getI2CCallouts() that will be used to look up the FRU
callouts to add to PELs for errors stemming from accessing devices,
either by a sysfs path, or in the case of the latter interface an I2C
bus and address.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I573d04632fd9fc6356a0ff53f85c2a2c13038962

show more ...

PEL: Simplify test makefile

The test helpers pel_utils.cpp and paths.cpp were getting compiled for
each testcase that uses them. Instead, use LDADD so they only get
compiled once.

Signed-off-by: M

PEL: Simplify test makefile

The test helpers pel_utils.cpp and paths.cpp were getting compiled for
each testcase that uses them. Instead, use LDADD so they only get
compiled once.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I86e6590ef67630de0515f6df83dbe5ff7ef12768

show more ...

PEL: Read the compatible system names property

The chassis object in the inventory has (or rather at the time of this
writing: will have) a Names property that contains a list of the
compatible syst

PEL: Read the compatible system names property

The chassis object in the inventory has (or rather at the time of this
writing: will have) a Names property that contains a list of the
compatible system types for the current system. An example is:
["company-systemA-4G", "company-systemA", "company"].

Add this to the DataInterface class, and remove the previous
'getSystemType' API that was there but was still stubbed out.

Also change all the calls from getSystemType() to the new call
getSystemNames(), and check against all entries in that array to see if
the desired name applies to the current system.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I86aa0c15c564153fea612f407c161dfe9041fce6

show more ...

ensure time delay in time based test

On some faster machines, the TimeBasedIDTest fails due to there being no
time difference between the time based ID's. Ensure there is always a
time difference wi

ensure time delay in time based test

On some faster machines, the TimeBasedIDTest fails due to there being no
time difference between the time based ID's. Ensure there is always a
time difference with a delay.

Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: If69c3aead8010f016e13d44f1e106cbc31d0b046

show more ...