History log of /openbmc/phosphor-logging/test/ (Results 251 – 275 of 290)
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
289aa47720-Sep-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Create PrivateHeader from parameters

Add a constructor to the PrivateHeader class so it can be built from the
creator's component ID, the OpenBMC log ID, and the creation timestamp.

This will

PEL: Create PrivateHeader from parameters

Add a constructor to the PrivateHeader class so it can be built from the
creator's component ID, the OpenBMC log ID, and the creation timestamp.

This will be used when creating PELs from OpenBMC event logs.

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

show more ...

93e2932f20-Sep-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Read SRC fields out of the registry

The SRC (System Reference code) is a section in the PEL and several of
its fields are sourced from the message registry.

Signed-off-by: Matt Spinler <spinle

PEL: Read SRC fields out of the registry

The SRC (System Reference code) is a section in the PEL and several of
its fields are sourced from the message registry.

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

show more ...

367144cf19-Sep-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Find an entry in the message registry JSON

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

PEL: Find an entry in the message registry JSON

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

show more ...

835a869327-Aug-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Support for going between PELs & registry

Add tables that allow one to go between how a PEL field actually shows
up in the PEL (raw bytes) and how it shows up in the message registry (a
string

PEL: Support for going between PELs & registry

Add tables that allow one to go between how a PEL field actually shows
up in the PEL (raw bytes) and how it shows up in the message registry (a
string enumeration). The tables also have a column to show a string
description of that value that can be used by the parser, though for now
those descriptions are all left at "TODO".

There only needs to be a table for a PEL field when there is a
corresponding message registry field that is a string enumeration, so
that when code looks up an error in the message registry it knows what
to fill in the PEL with.

Also provide APIs to look up a row in the table by either the PEL value
or the message registry value.

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

show more ...

09d6400f11-Sep-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Add FailingMTMS PEL section class

This PEL section contains the Machine Type-Model and Serial number of
the enclosure and is required for BMC PELs. In the constructor that
creates the section

PEL: Add FailingMTMS PEL section class

This PEL section contains the Machine Type-Model and Serial number of
the enclosure and is required for BMC PELs. In the constructor that
creates the section from scratch, it gets those values from the
DataInterface class.

This commit doesn't hook this section into the PEL class as there are
some prerequisites that still need to be done first.

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

show more ...

c8705e2b11-Sep-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Interface to collect system data

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 ty

PEL: Interface to collect system data

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

show more ...

b666433910-Sep-2019 Matt Spinler <spinler@us.ibm.com>

PEL: MTMS class to handle the type-model and SN

This class represents the (M)achine (T)ype-(M)odel (S)erial number
structure for the PEL, where it is used in both the ExtendedUserHeader
and FailingM

PEL: MTMS class to handle the type-model and SN

This class represents the (M)achine (T)ype-(M)odel (S)erial number
structure for the PEL, where it is used in both the ExtendedUserHeader
and FailingMTMS sections.

It consists of an 8 byte machine type+model field of the form TTT-MMMM,
followed by a 12 byte machine serial number field. Unused bytes are set
to 0.

Note that this is not a PEL section itself. It's just used by other PEL
sections.

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

show more ...

27d8281411-Sep-2019 John Wang <wangzqbj@inspur.com>

Move to new association interface

A new association interface is defined in phosphor-dbus-interfaces
It would be nice to move the local version of the interface
to the new one.

The behavior of how

Move to new association interface

A new association interface is defined in phosphor-dbus-interfaces
It would be nice to move the local version of the interface
to the new one.

The behavior of how association work is described here:
https://github.com/openbmc/docs/blob/master/object-mapper.md#associations

Partially resolves openbmc/openbmc#3584

Tested: Create a new log using the Create interface, see that
org.openbmc.Associations has been replaced by the xyz one and
2 association objects are created by the mapper.

Signed-off-by: John Wang <wangzqbj@inspur.com>
Change-Id: I9bcddd4765b12224967383bab2dbaa6d273e2790

show more ...

cf5a8d0f05-Sep-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Add a flatten() to Section base class

To prepare for supporting PEL sections that can be in any order,
which will probably be stored in a std::vector<unique_ptr<Section>>,
add a pure virtual fu

PEL: Add a flatten() to Section base class

To prepare for supporting PEL sections that can be in any order,
which will probably be stored in a std::vector<unique_ptr<Section>>,
add a pure virtual function in the Section base class so this list
of sections can just be iterated on and have every object in it
flattened.

This flatten() call replaces the operator<<(Stream&, <object>)
functions currently in use, so also convert the operator>> to
unflatten() to make things consistent.

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

show more ...

5fa87f0827-Aug-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Get BCD time from epoch milliseconds

Add a new BCD time conversion function which will be used in a future
commit to convert an OpenBMC event log timestamp into BCD time.

Signed-off-by: Matt S

PEL: Get BCD time from epoch milliseconds

Add a new BCD time conversion function which will be used in a future
commit to convert an OpenBMC event log timestamp into BCD time.

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

show more ...

2813f36d19-Jul-2019 Matt Spinler <spinler@us.ibm.com>

PEL: New repository method to get PEL data

Add the getPELData() function on the Repository class to return
PEL data based on a PEL ID or OBMC event log ID.

The intended use for this will be a D-Bus

PEL: New repository method to get PEL data

Add the getPELData() function on the Repository class to return
PEL data based on a PEL ID or OBMC event log ID.

The intended use for this will be a D-Bus method, mainly used for
debug via the REST interface, to get the PEL data off the BMC when
only the OpenBMC event log ID is known, which will be the case until
the Redfish APIs are ready.

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

show more ...

475e574d18-Jul-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Remove a PEL based on an ID

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

PEL: Remove a PEL based on an ID

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

show more ...

89fa082a17-Jul-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Add repository to save PELs

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 reposi

PEL: Add repository to save PELs

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

show more ...

cb6b059e16-Jul-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Add PEL class

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

PEL: Add PEL class

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

show more ...

df13bdb610-Jul-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Add function to generate unique PEL IDs

Create generatePELID() to return a unique 4B PEL ID every time it is
called. It will start at a base value, and then increment by 1 each
time. It uses a

PEL: Add function to generate unique PEL IDs

Create generatePELID() to return a unique 4B PEL ID every time it is
called. It will start at a base value, and then increment by 1 each
time. It uses a file to save the next value to use.

This will be used by the PEL handling code to create unique values
for the error log ID field in the Private Header section.

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

show more ...

03c1d91510-Jul-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Add UserHeader class

The second section in a PEL is always the 'User Header' section. This
commit adds a class to represent that. Right now, the only constructor
available is filling in its d

PEL: Add UserHeader class

The second section in a PEL is always the 'User Header' section. This
commit adds a class to represent that. Right now, the only constructor
available is filling in its data fields from a PEL stream.

Several of the fields in this section have predefined values that are
defined by the PEL specification. Defining any constants or enums for
those will be left to future commits where they will actually be used.

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

show more ...

d3335dfa10-Jul-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Add PrivateHeader class

The first section in a PEL is always the 'Private Header' section. This
commit adds a class to represent that. Right now, the only constructor
available is filling in

PEL: Add PrivateHeader class

The first section in a PEL is always the 'Private Header' section. This
commit adds a class to represent that. Right now, the only constructor
available is filling in its data fields from a PEL stream.

The Section base class, which will be the base class of all PEL
sections, is also being introduced here. It contains the section header
structure, and a valid flag that derived classes can use.

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

show more ...

1b5c72b510-Jul-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Add PEL section header structure

A PEL is made up of sections, and every section has an 8B
section header. This commit adds a SectionHeader structure
that will represent that header. It will

PEL: Add PEL section header structure

A PEL is made up of sections, and every section has an 8B
section header. This commit adds a SectionHeader structure
that will represent that header. It will then be included in
all upcoming PEL sections.

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

show more ...

df797f2b09-Jul-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Add BCD time helpers for PELs

A PEL stores time in BCD, with a byte each for:
* year MSB
* year LSB
* month
* day
* hour
* minutes
* seconds
* hundredths

This commit adds a structure to repres

PEL: Add BCD time helpers for PELs

A PEL stores time in BCD, with a byte each for:
* year MSB
* year LSB
* month
* day
* hour
* minutes
* seconds
* hundredths

This commit adds a structure to represent this, and functions to:
* Create a BCD structure from a std::chrono::time_point
* Convert any number to BCD
* Write the BCD structure into a Stream
* Extract a BCD structure from a Stream

Refresher: The BCD value of 32 is 0x32.

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

show more ...

113ad28c09-Jul-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Add Stream class to manipulate PEL data

This stream inserts data into and extracts data from the vector<uint8_t>
that it is given in its contructor. That vector is how PEL data is
stored. Thi

PEL: Add Stream class to manipulate PEL data

This stream inserts data into and extracts data from the vector<uint8_t>
that it is given in its contructor. That vector is how PEL data is
stored. This object takes care of the endian conversion for fields that
require it, as PEL data is big endian.

On writes, it will expand the vector if necessary.

An exception will be thrown an invalid access is attempted, such as
trying to extract a value when at the end of the data.

It provides >> and << operators for common data types, as well as
read()/write() functions when using other types.

Example:

std::vector<uint8_t> data;
Stream stream{data};

uin32_t value = 0x12345678;
stream << value;

stream.offset(0);

uint32_t newValue;
stream >> newValue;

assert(value == newValue);

uint8_t buf[3000] = {0};
stream.write(buf, 3000);

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

show more ...

15ee6aee08-Jul-2019 Matt Spinler <spinler@us.ibm.com>

PEL: Add class to wrap AdditionalData

The AdditionalData property on the xyz.openbmc_project.Logging.Entry
interface is a vector of strings of the form: "KEY=VALUE". The
PEL processing code will b

PEL: Add class to wrap AdditionalData

The AdditionalData property on the xyz.openbmc_project.Logging.Entry
interface is a vector of strings of the form: "KEY=VALUE". The
PEL processing code will be interested in those keys and values, and
this class adds a way to get at those values based on a key without
having to do string parsing each time. It returns an
std::optional<std::string> value, and if the key isn't found, then the
std::optional value will be empty.

For Example:
AdditionalData ad{additionalDataPropertyValue};

// Get the value for the FOO key
std::optional<std::string> val = ad.getValue("FOO");

if (val)
std::cout << (*val).size();

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

show more ...

1787c52109-Jul-2019 Matt Spinler <spinler@us.ibm.com>

Add libstdc++fs to test_ldflags Makefile var

Every testcase that uses test_ldflags also needs that library,
so just pull it in from that single place instead of in each
testcase.

Signed-off-by: Mat

Add libstdc++fs to test_ldflags Makefile var

Every testcase that uses test_ldflags also needs that library,
so just pull it in from that single place instead of in each
testcase.

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

show more ...

99c2b40523-May-2019 Matt Spinler <spinler@us.ibm.com>

OpenPower PEL Extension support framework

The goal of extensions is to extend phosphor-logging's
`xyz.openbmc_project.Logging.Entry` log support to allow other log
formats to be created without incu

OpenPower PEL Extension support framework

The goal of extensions is to extend phosphor-logging's
`xyz.openbmc_project.Logging.Entry` log support to allow other log
formats to be created without incurring extra D-Bus call overhead.

The README.md change in this commit provides additional documentation on
how extensions work. The summary is that they allow code that resides
in this repository to provide functions that can be called at certain
points (startup, log creation/deletion) such that the code can then
create their own logs based on the contents of an OpenBMC log. A
specific extension's code is compiled in using a --enable configure
option, so platforms that did not use those log formats would incur no
performance/size penalties.

This commit provides the support for extensions, plus a basic OpenPower
PEL (Platform Event Log) extension as the first extension. PELs are
event logs used only on some OpenPower systems.

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

show more ...

0a0b5ea522-May-2019 Santosh Puranik <santosh.puranik@in.ibm.com>

rsyslod: Change disable action

This commit changes the way remote logging is disabled.
Prior to this, we would create/delete the
RSYSLOG_SERVER_CONFIG_FILE to enable/disable remote logging.

Deletin

rsyslod: Change disable action

This commit changes the way remote logging is disabled.
Prior to this, we would create/delete the
RSYSLOG_SERVER_CONFIG_FILE to enable/disable remote logging.

Deleting the file would cause systemd to spin while it tried
to trigger the syslog service via socket activation. So this
commit reverts commits 40a7406097c0b5b0670c5987f6fe8c902d65562d
and e165ea956c5557c2b470869d252c80744227b00f and then:

To disable remote logging, we now simply ask that rsyslog
ignore all incoming messages. This is done by using a special
'~' rule for all messages.

Tested:
-- Verified that systemd no longer spins while trying to
activate rsyslog with default config.
-- Verified that setting a remote logging server over the
REST API still works.

Signed-off-by: Santosh Puranik <santosh.puranik@in.ibm.com>
Change-Id: Ife217a84395aaf32b775b7a84f85fc6310df3e7c

show more ...

e165ea9511-Jan-2019 Deepak Kodihalli <dkodihal@in.ibm.com>

rsyslogd: don't start without actions

Rsyslog is currently used only for remote logging. The daemon would run
though (started by systemd) even when remote logging has not been
configured. In other w

rsyslogd: don't start without actions

Rsyslog is currently used only for remote logging. The daemon would run
though (started by systemd) even when remote logging has not been
configured. In other words, it would run without any actions.

With Yocto 2.6, rsyslogd won't run without any actions. Hence, rsyslogd
is now started only on the condition that the remote logging config
file is present.

Change-Id: Iae11d6912e60765ecb774b663d44b4e3c6f381a3
Signed-off-by: Deepak Kodihalli <dkodihal@in.ibm.com>

show more ...

1...<<1112