All of lore.kernel.org
 help / color / mirror / Atom feed
* Discrete sensors for host error monitor signals
@ 2020-07-14 18:03 Patrick Voelker
  2020-07-17 17:10 ` Varun Sampat
  0 siblings, 1 reply; 4+ messages in thread
From: Patrick Voelker @ 2020-07-14 18:03 UTC (permalink / raw)
  To: OpenBMC (openbmc@lists.ozlabs.org)

[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 5862 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: Discrete sensors for host error monitor signals
  2020-07-14 18:03 Discrete sensors for host error monitor signals Patrick Voelker
@ 2020-07-17 17:10 ` Varun Sampat
  2020-07-20 18:56   ` Patrick Voelker
  0 siblings, 1 reply; 4+ messages in thread
From: Varun Sampat @ 2020-07-17 17:10 UTC (permalink / raw)
  To: Patrick Voelker; +Cc: OpenBMC (openbmc@lists.ozlabs.org)

[-- Attachment #1: Type: text/plain, Size: 7668 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 22798 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread
* RE: Discrete sensors for host error monitor signals
  2020-07-17 17:10 ` Varun Sampat
@ 2020-07-20 18:56   ` Patrick Voelker
  2020-07-22  0:48     ` Varun Sampat
  0 siblings, 1 reply; 4+ messages in thread
From: Patrick Voelker @ 2020-07-20 18:56 UTC (permalink / raw)
  To: Varun Sampat; +Cc: OpenBMC (openbmc@lists.ozlabs.org)

[-- Attachment #1: Type: text/plain, Size: 9029 bytes --]

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@gmail.com]
Sent: Friday, July 17, 2020 10:11 AM
To: Patrick Voelker
Cc: OpenBMC (openbmc@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@phoenix.com<mailto:Patrick_Voelker@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.

[-- Attachment #2: Type: text/html, Size: 31604 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: Discrete sensors for host error monitor signals
  2020-07-20 18:56   ` Patrick Voelker
@ 2020-07-22  0:48     ` Varun Sampat
  0 siblings, 0 replies; 4+ messages in thread
From: Varun Sampat @ 2020-07-22  0:48 UTC (permalink / raw)
  To: Patrick Voelker; +Cc: OpenBMC (openbmc@lists.ozlabs.org)

[-- Attachment #1: Type: text/plain, Size: 11653 bytes --]

Hi Patrick

Regarding you question about assigning 'event type' to the sensor, this is
how we have implemented it:

1. You are right about the 'getSensorEventTypeFromPath()' currently being
hardcoded to "threshold". The way we have implemented this is that in the
getSensorEventTypeFromPath() function, instead of returning 0x01 (or
threshold) as it is now, we only return 0x01 for threshold based sensor
types (such as 0x01, 0x02, 0x03, 0x04 or other 0x0b). For everything else
we return 0x6f. We use 6f as the event type for all discrete events. We
don't distinguish the event type on discrete sensors such as "digital
discrete" or "generic discrete"

2. For the discrete sensors, we create an sdr record for 'Type 3"
Event-only sensors in the phosphor-ipmi-host recipe in the
sensorhandler.hpp file where the full sdr record is currently defined. We
create one for Type 3 events only sensors based on the IPMI spec
description in section 43.3.

3. Now in the sensorcommands.cpp file (in intel-ipmi-oem), in the
ipmiStorageGetSDR function we check the getSensorEventTypeFromPath() and if
it is of type "discrete" as defined in step 1, we populate the fields based
on the type 3 record defined in step 2 and return success.

For creating a value property, you can register_property for 'Value' when
you create the sensor object and interface like I described in step 3 of my
previous email. Off the top of my head, I am not sure how to assert and
de-assert based on changes to the 'value' of discrete sensors (at least
that's my interpretation of what you're trying to do, please correct me if
I'm wrong) so I can't be of much help there. In our case we just use the
IpmiSelAdd method-call to assert or de-assert directly in our event handler
like I described in steps 6 and 7 of my previous email.

Hope that helps.

-Varun

On Mon, Jul 20, 2020 at 11:56 AM Patrick Voelker <
Patrick_Voelker@phoenix.com> wrote:

> 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@gmail.com]
> *Sent:* Friday, July 17, 2020 10:11 AM
> *To:* Patrick Voelker
> *Cc:* OpenBMC (openbmc@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@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.
>
>

[-- Attachment #2: Type: text/html, Size: 33287 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-07-22  0:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-14 18:03 Discrete sensors for host error monitor signals Patrick Voelker
2020-07-17 17:10 ` Varun Sampat
2020-07-20 18:56   ` Patrick Voelker
2020-07-22  0:48     ` Varun Sampat

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.