entity-manager experiments
Patrick Venture
venture at google.com
Wed Jul 31 04:41:19 AEST 2019
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.
>
> >
> > >>
> > >> 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