entity-manager experiments
Patrick Venture
venture at google.com
Wed Jul 31 06:25:40 AEST 2019
On Tue, Jul 30, 2019 at 1:03 PM Patrick Venture <venture at google.com> wrote:
>
> 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.
Ok, so what's happening is it's finding the name, but it's an empty
entry, so I'm adding a check to see if the result is found and
empty(), accordingly. Before, it was ok then adding the empty entry,
and then later it finds the entry and add _0 as the appending onto
empty.
So, now if it's empty from board (or not found) it'll try the product
name, and if that's empty (or not found) it'll name it unknown.
Patch going up once my testing is done.
>
> >
> > >
> > >>
> > >>>
> > >>>>>
> > >>>>> 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