Discrete sensors for host error monitor signals
Varun Sampat
varunsampat at gmail.com
Wed Jul 22 10:48:43 AEST 2020
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 at 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 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> 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/20200721/3d0ac5cd/attachment-0001.htm>
More information about the openbmc
mailing list