Discrete sensors for host error monitor signals

[Varun Sampat]

Hi Patrick

Though we don't use host-error-monitor at Twitter, we do have a number of
discrete sensors implemented. I can provide some details that can hopefully
help get you started.

I should mention though, the below steps are only applicable if you're
using 'dbus-sensors' for your sensors and the phosphor-sel-logger.

1. Include the 'intel-ipmi-oem' recipe in your package

2. In the 'intel-ipmi-oem' recipe, in the file called sdrutils.hpp, you
will find a bunch of enumerated entries for different (threshold based)
sensor types such as voltage, current etc. You can add discrete sensor type
you want here, for example for CATERRs it probably would be of the type
"processor" (0x07)

3. You don't  necessarily need to add the discrete sensor to entity-manager
(you can if you like). Instead, under dbu-sensors you need to create a
service and add an interface for your sensor. We have implemented by adding
code in dbus-sensors that has a list of event-only sensors and our code
loops through and adds all of them. However to start out, you can just do
it for a single discrete sensor by doing the following:
a. create a file (say processorerror.cpp) along the same lines as one of
the existing sensor types
b. request a service name using "request->name"
c. register your object path and interface
The above file would essentially do nothing other than just create a dbus
sensor.

4. Create entries in the CMakeLists.txt file in dbus-sensors to build your
.cpp file and make sure it corresponds with the sensor type you created in
intel-ipmi-oem in step 2.

5. Once the above step is done, if you build an image, you should see the
sensor you created (say something like
"/xyz/openbmc_project/sensors/processor/Processor_Error" ) if you do
"ipmitool sdr elist all". The sensor will be created with a dynamically
assigned sensor number just like all the threshold based sensors. However,
instead of displaying a value like it would for a threshold sensor it will
say "Event-Only". At this point your discrete sensor is created but doesn't
really do anything

6. Now, in order to generate a SEL, we use the IpmiSelAdd method that is
present in the sel-logger service:

# busctl introspect  xyz.openbmc_project.Logging.IPMI
/xyz/openbmc_project/Logging/IPMI

NAME                                TYPE      SIGNATURE RESULT/VALUE FLAGS

*org.freedesktop.DBus.Introspectable* interface -         -            -

.Introspect                         method    -         s            -

*org.freedesktop.DBus.Peer          * interface -         -            -

.GetMachineId                       method    -         s            -

.Ping                               method    -         -            -

*org.freedesktop.DBus.Properties    * interface -         -            -

.Get                                method    ss        v            -

.GetAll                             method    s         a{sv}        -

.Set                                method    ssv       -            -

.PropertiesChanged                  signal    sa{sv}as  -            -

*xyz.openbmc_project.Logging.IPMI   * interface -         -            -

.IpmiSelAdd                         method    ssaybq    q            -

.IpmiSelAddOem                      method    sayy      q            -

As you can see above, the IpmiSelAdd method takes 6 arguments, 'ssaybq' as
described in
https://dbus.freedesktop.org/doc/dbus-specification.html#type-system.
<https://dbus.freedesktop.org/doc/dbus-specification.html#type-system>
Looking at the code in phosphor-sel-logger where the IpmiSelAdd method is
registered, we can see what the ssaybq arguments correspond to:

ifaceAddSel->register_method(

        "IpmiSelAdd", [](const std::string &message, const std::string
&path,

                         const std::vector<uint8_t> &selData,

                         const bool &assert, const uint16_t &genId) {

Based on this, we can directly call the method using busctl to test if a
SEL is created for the discrete sensor. For example, for the sensor we
created in step 5, we could do the following to generate a SEL:
busctl call xyz.openbmc_project.Logging.IPMI
/xyz/openbmc_project/Logging/IPMI xyz.openbmc_project.Logging.IPMI
IpmiSelAdd ssaybq <message string> <sensor object path, i.e
"/xyz/openbmc_project/sensors/processor/Processor_Error">  <number of bytes
in the event data vector, which in this case would be 3>  <event data
vector>  < assert/de-assert yes/no>  <generator id, 0x0020 for bmc>

(the first 4 arguments after 'call' are the service, object, interface and
the method)

To give you an example, here is what the above command looks like for a
discrete sensor for a power button press:
Command:
# busctl call xyz.openbmc_project.Logging.IPMI
/xyz/openbmc_project/Logging/IPMI xyz.openbmc_project.Logging.IPMI
IpmiSelAdd ssaybq "SEL Entry"
"/xyz/openbmc_project/sensors/pwr_button/POWER_BUTTON" 3 {0x00,0x01,0x00}
yes 0x20

Sel generated:
f | 07/17/20 | 16:49:01 UTC | Button POWER BUTTON | Power Button pressed |
Asserted

7. If you have a service that triggers on an event, you could directly call
the above command to generate a SEL in your service file. For example, we
have a gpio service that triggers on certain events and we directly call
the above command from the service file. In other cases we call a method to
generate the SEL in code in the event "handler" function. This might be
more relevant for our host-error-monitor case. Here is an example from our
code for how we call the IpmiSelAdd method:

sdbusplus::message::message writeSEL = conn->new_method_call(

            ipmiSelService, ipmiSelPath, ipmiSelAddInterface, "IpmiSelAdd");

        writeSEL.append(ipmiSelAddMessage, dbusPath, eventData, assert,
genId);


        try

        {

            conn->call(writeSEL);

        }

Here, conn is the "shared_ptr". The other arguments are pretty much the
same as described in the busctl command in #6.  Not sure how this would
work with host-error-monitor but you can try it with the relevant
shared_ptr in host_error_monitor.cpp and it might possibly work.

Hope this helps.

-Varun


On Tue, Jul 14, 2020 at 3:07 PM Patrick Voelker <Patrick_Voelker at phoenix.com>
wrote:

> Hi, I’d like to log IPMI SEL events for changes in the signals monitored
> by OpenBMC/host-error-monitor.  I don’t have much experience with OpenBMC’s
> sensors yet so I’m not sure what the best approach is and am looking for
> some guidance.
>
>
>
> I haven’t found a good example yet of a IPMI discrete sensor and I don’t
> want to put IPMI specific information into host-error-monitor to directly
> add SEL events via phosphor-sel-logger.
>
>
>
> Here’s my understanding thus far :
>
>
>
> * A module needs to instantiate dbus sensors representing the signals
> being monitored.  This could be done in host-error-monitor or duplicate
> some of the functionality in dbus-sensors.  Is there a benefit to extending
> one over the other?
>
>
>
> * One or more IPMI SDRs should be created for the IPMI sensors needed to
> group all the necessary discrete offsets.  If I’m using entity-manager in
> my build, is that where I would define this sensor?  If not, is there some
> other way to accomplish this?
>
>
>
> * phosphor-sel-logger then needs to monitor (match) dbus discrete sensor
> property changes to create appropriate IPMI and redfish logs for the events
> as they occur.
>
>
>
> Does that sound about right? Thanks in advance for your help.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200717/e0dcb31e/attachment-0001.htm>