Discrete sensors for host error monitor signals

[Patrick Voelker]

Varun, thanks so much for your response.

I see that I can add to SensorTypeCodes in intel-ipmi-oem/include/sdrutils.hpp and that it will be used to match against the dbus sensor path.  How though do you recommend assigning the sensor event type to the sensor?  getSensorEventTypeFromPath() is currently hardcoded to “threshold” and I don’t see how I could determine it from the sensor path (the way they are currently implemented.)

I’d like my new sensors to be readable so I’m planning on adding a "xyz.openbmc_project.Sensor.Value” interface.  Also, I’d like phosphor-sel-logger to be able to match on changes to be able to automatically generate events so that I don’t need to embed IPMI specific information into the dbus-sensors module.  I think I need a dbus interface akin to "xyz.openbmc_project.Sensor.Threshold.Warning" that would instead be my assertion and deassertion event masks.  Do these interfaces and properties look reasonable?

xyz.openbmc_project.Sensor.Discrete.Assertion
.AssertionAlarmMask
xyz.openbmc_project.Sensor.Discrete.Deassertion
.DeassertionAlarmMask

As always, if I’m re-inventing the wheel here and there’s an example that already exists that I can follow, please point me in the right direction.


From: Varun Sampat [mailto:varunsampat at gmail.com]
Sent: Friday, July 17, 2020 10:11 AM
To: Patrick Voelker
Cc: OpenBMC (openbmc at lists.ozlabs.org)
Subject: Re: Discrete sensors for host error monitor signals

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<mailto: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/20200720/469da9b4/attachment-0001.htm>