entity-manager experiments

Patrick Venture venture at google.com
Wed Jul 31 06:03:38 AEST 2019


On Tue, Jul 30, 2019 at 12:01 PM James Feist
<james.feist at linux.intel.com> wrote:
>
> On 7/30/19 11:41 AM, Patrick Venture wrote:
> > On Mon, Jul 29, 2019 at 1:05 PM Patrick Venture <venture at google.com> wrote:
> >>
> >> On Mon, Jul 29, 2019 at 12:58 PM Ed Tanous <ed.tanous at intel.com> wrote:
> >>>
> >>> On 7/26/19 4:45 PM, Patrick Venture wrote:
> >>>> On Fri, Jul 26, 2019 at 4:40 PM Patrick Venture <venture at google.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I was curious if you had any thoughts on what is missing here -- I
> >>>>> wrote a basic json file:
> >>>>>
> >>>>> razorback.json:
> >>>>> {
> >>>>>      "Exposes": [
> >>>>>          {
> >>>>>              "Address": "$address",
> >>>>>              "Bus": "$bus",
> >>>>>              "Name": "Razorback",
> >>>>>              "Type": "EEPROM"
> >>>>>          },
> >>>>>          {
> >>>>>              "Address": "0x4c",
> >>>>>              "Bus": "$bus",
> >>>>>              "Name": "Razorback Temp Sensor",
> >>>>>              "Type": "TMP421"
> >>>>>          }
> >>>>>      ],
> >>>>>      "Name": "Razorback Board",
> >>>>>      "Probe" : "xyz.openbmc_project.FruDevice({'PRODUCT_PRODUCT_NAME':
> >>>>> '.*Razorback'})",
> >>>
> >>> I'd recommend taking out the wildcard if you can if you don't expect
> >>> there to be multiple models of this board.  We've gotten trapped a
> >>> little in the past with next-gen boards sporting a similar product name
> >>> (think 2019_Razorback vs 2020_Razorback) and configs getting applied
> >>> that shouldn't have.
> >>
> >> Thanks.
> >>
> >>>
> >>>>>      "Type": "Board",
> >>>>>      "xyz.openbmc_project.Inventory.Decorator.Asset": {
> >>>>>          "Manufacturer": "$PRODUCT_MANUFACTURER",
> >>>>>          "Model": "$PRODUCT_PRODUCT_NAME",
> >>>>>          "PartNumber": "$PRODUCT_PART_NUMBER",
> >>>>>          "SerialNumber": "$PRODUCT_SERIAL_NUMBER"
> >>>>>      }
> >>>>> }
> >>>>>
> >>>>> And it finds it:
> >>>>> Service xyz.openbmc_project.EntityManager:
> >>>>> `-/xyz
> >>>>>    `-/xyz/openbmc_project
> >>>>>      |-/xyz/openbmc_project/EntityManager
> >>>>>      `-/xyz/openbmc_project/inventory
> >>>>>        `-/xyz/openbmc_project/inventory/system
> >>>>>          `-/xyz/openbmc_project/inventory/system/board
> >>>>>            `-/xyz/openbmc_project/inventory/system/board/Razorback_Board
> >>>>>              |-/xyz/openbmc_project/inventory/system/board/Razorback_Board/Razorback
> >>>>>              `-/xyz/openbmc_project/inventory/system/board/Razorback_Board/Razorback_Temp_Sensor
> >>>>>
> >>>>> Service xyz.openbmc_project.FruDevice:
> >>>>> `-/xyz
> >>>>>    `-/xyz/openbmc_project
> >>>>>      `-/xyz/openbmc_project/FruDevice
> >>>>>        `-/xyz/openbmc_project/FruDevice/_0
> >>>>>
> >>>>> I don't know why it's named _0, but I can debug that late
> >>> The logic for that name is right here:
> >>> https://github.com/openbmc/entity-manager/blob/441c7a86749b2331863b115e141033e735bd6ffc/src/FruDevice.cpp#L549
> >>>
> >>> I'm guessing either the board section product name field or the product
> >>> section product name field is blank.  In that, we should probably check
> >>> for empty string and move on to the next one.
> >>
> >> Thanks.  I'll take a look there and write up a patch to fix it.
> >
> > Dug into it and found that it is finding two of those FRUs on my
> > platform, as it should, and it installs one with _0 then the other
> > just overwrites it also with _0.
> >
> > I'll look into whether it's feasible to add a global list inside
> > FruDevice so it can just add a number to the end or something.
>
> This should be doing it:
> https://github.com/openbmc/entity-manager/blob/441c7a86749b2331863b115e141033e735bd6ffc/src/FruDevice.cpp#L596
>
>
> My guess looking at this is that the for loop needs to be changed to
> loop through until it doesn't find the same product name. If you
> restarted the loop when index was incremented it would fix your issue I
> think.

Thanks, I am debugging it now and should have a patch for review before long.

>
> >
> >>
> >>>
> >>>>>
> >>>>> So I introspect on it:
> >>>>> busctl introspect --no-pager xyz.openbmc_project.EntityManager
> >>>>> /xyz/openbmc_project/inventory/system/board/Razorback_Board/Razorback_Temp_Sensor
> >>>>> 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.Configuration.TMP421 interface -         -
> >>>>>                -
> >>>>> .Address                                 property  t         76
> >>>>>                emits-change
> >>>>> .Bus                                     property  t         17
> >>>>>                emits-change
> >>>>> .Name                                    property  s
> >>>>> "Razorback Temp Sensor" emits-change
> >>>>> .Type                                    property  s         "TMP421"
> >>>>>                emits-change
> >>>>>
> >>>>> and all that looks correct, and now there's an i2c device at 17-004c,
> >>>>> but no hwmon path, and:
> >>>>>
> >>>>> Jul 25 00:27:24 machine intrusion-sensor[2654]: Error communicating to
> >>>>> entity manager
> >>>>> Jul 25 00:27:24 machine intrusion-sensor[2654]: error communicating to
> >>>>> entity manager
> >>>>> Jul 25 00:27:24 machine fansensor[2671]: Error communicating to entity manager
> >>>>> Jul 25 00:27:24 machine fansensor[2671]: error communicating to entity manager
> >>>>> Jul 25 00:27:24 machine fansensor[2671]: Error calling entity manager
> >>>>> Jul 25 00:27:24 machine adcsensor[2658]: Error communicating to entity manager
> >>>>> Jul 25 00:27:24 machine adcsensor[2658]: error communicating to entity manager
> >>>>> Jul 25 00:27:25 machine mcutempsensor[2689]: Error contacting entity manager
> >>>>> Jul 25 00:27:25 machine hwmontempsensor[2675]: Error communicating to
> >>>>> entity manager
> >>>>> Jul 25 00:27:25 machine hwmontempsensor[2675]: error communicating to
> >>>>> entity manager
> >>>>> Jul 25 00:27:26 machine psusensor[2677]: Error communicating to entity manager
> >>>>> Jul 25 00:27:26 machine psusensor[2677]: error get sensor config from
> >>>>> entity manager
> >>>>> Jul 25 00:27:27 machine ipmbsensor[2674]: Error contacting entity manager
> >>>>> Jul 25 00:27:27 machine cpusensor
> >>>> [2666]: Error communicating to entity manager
> >>>>> Jul 25 00:27:27 machine entity-manager[2694]: Clearing previous configuration
> >>>>>
> >>>>> Service xyz.openbmc_project.HwmonTempSensor:
> >>>>> Only root object discovered.
> >>>>>
> >>>>> Any thoughts on the disconnect?  Have you seen anything like this?
> >>>>
> >>>> I had a hunch the driver was missing:
> >>>>
> >>>> tmp/work-shared/machine/kernel-build-artifacts/.config:1827:#
> >>>> CONFIG_SENSORS_TMP421 is not set
> >>>>
> >>>> ... ok, so that makes sense then! :D  Will try fixing that first!
> >>>>
> >>>
> >>> That would do it.
> >>>
> >>>>>
> >>>>> Patrick


More information about the openbmc mailing list