PEL: Disable the default log entry capping

Turn off phosphor-logging's built in mechanism of capping the amount of
logs now that the code to do this based on PEL rules is in place.

Signed-off-by: M

PEL: Disable the default log entry capping

Turn off phosphor-logging's built in mechanism of capping the amount of
logs now that the code to do this based on PEL rules is in place.

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

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: Add size, creator, sev to repo attributes

Have the Repository class track the disk usage, creator ID and severity
of each PEL along with the attributes already tracked so that they can
be used

PEL: Add size, creator, sev to repo attributes

Have the Repository class track the disk usage, creator ID and severity
of each PEL along with the attributes already tracked so that they can
be used in the future for categorizing PELs to prune.

Note the size field is the amount of space the PEL file uses on disk, as
determined by the stat() function call, and not just the regular file
size, as the pruning algorithm is based on disk usage.

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

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 ...

PEL: Document PEL retention and pruning rules

The amount of disk space that PELs can take up on the BMC as well as the
total number of PELs will be capped. Document what happens when this
cap is re

PEL: Document PEL retention and pruning rules

The amount of disk space that PELs can take up on the BMC as well as the
total number of PELs will be capped. Document what happens when this
cap is reached.

At a high level, this includes removing old PELs from several
categories until those categories take up only a certain percentage of
the allocated space.

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

show more ...

PEL: Add a test error to the message registry

This error has both procedure and symbolic FRU callouts. Defining these
callouts in the registry is the only way to have these types of
callouts added

PEL: Add a test error to the message registry

This error has both procedure and symbolic FRU callouts. Defining these
callouts in the registry is the only way to have these types of
callouts added to a PEL.

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

show more ...

PEL: Add Read/WriteFailure registry entries

These are device access errors used by code like phosphor-hwmon,
openpower-occ-control, and phosphor-power.

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

PEL: Add Read/WriteFailure registry entries

These are device access errors used by code like phosphor-hwmon,
openpower-occ-control, and phosphor-power.

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

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 phosphor-power errors

Add entries to the message registry JSON file for power-related errors.
These errors will be logged by applications in the phosphor-power
repository.

Note that more p

PEL: Add phosphor-power errors

Add entries to the message registry JSON file for power-related errors.
These errors will be logged by applications in the phosphor-power
repository.

Note that more power-related errors will likely be added in the future.
This is an initial set of entries used by the phosphor-regulators
application within that repository.

Tested:
* Ran validation tool
* Created OpenBMC error logs for all the new message registry entries.
Used the D-Bus interface to create the error logs.
* Verified that PELs were created with the correct field values.

Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>
Change-Id: I94165c04b894638a74a679a2f9c73b510104cd9c

show more ...

PEL: Add BMC code maintenance procedure

Maintenance procedures are part of the PEL callout section. This
procedure is used to indicate the problem is due to code (a bug).

Signed-off-by: Matt Spinl

PEL: Add BMC code maintenance procedure

Maintenance procedures are part of the PEL callout section. This
procedure is used to indicate the problem is due to code (a bug).

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

show more ...

PEL: Point action flags documention to its rules

Add a link from where the PEL action flags are described to the rules on
how the code sets them.

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

PEL: Point action flags documention to its rules

Add a link from where the PEL action flags are described to the rules on
how the code sets them.

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

show more ...

PEL: Fix SRC type check in process_registry.py

The Type field is in the SRC subsection of a registry entry.

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

PEL: Fix SRC type check in process_registry.py

The Type field is in the SRC subsection of a registry entry.

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

show more ...

PEL: Fix hexdump output in peltool

Hexdump output of UserData section has 8 extra bytes that are not part
of the section data. This fix truncates the extra data to show the true
hexdump output.

Sig

PEL: Fix hexdump output in peltool

Hexdump output of UserData section has 8 extra bytes that are not part
of the section data. This fix truncates the extra data to show the true
hexdump output.

Signed-off-by: Harisuddin Mohamed Isa <harisuddin@gmail.com>
Change-Id: I7c0b46fb85b94265ae4f960eb4ef36eaf293db3b

show more ...

PEL: Document the supported dev callout types

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

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: Let SRC class create a debug section

Add functionality so that when the SRC PEL section is being created, it
can save debug data (a vector of strings) along the way, and the PEL
class will then

PEL: Let SRC class create a debug section

Add functionality so that when the SRC PEL section is being created, it
can save debug data (a vector of strings) along the way, and the PEL
class will then add that data into a JSON UserData section with any
other debug data. The PEL class will then also write the debug data to
the journal.

This will be used for things like failure messages when looking up
callouts, additional information for device callouts, etc.

The functionality to save debug data is in the Section base class, so in
the future other Section classes can also save debug data for display in
the PEL.

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

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: 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 ...