In the latest Master,
snippet
Aug 03 15:53:03 witherspoon ipmid[1149]: Error in finding sensor dbusCommand: GetSubTree Interface:xyz.openbmc_project.State.Decorator.OperationalStatus
Aug 03 15:53:03 witherspoon ipmid[1149]: The operation failed internally.
Aug 03 15:53:03 witherspoon ipmid[1149]: terminate called after throwing an instance of 'sdbusplus::xyz::openbmc_project::Common::Error::InternalFailure'
Aug 03 15:53:03 witherspoon ipmid[1149]: what(): xyz.openbmc_project.Common.Error.InternalFailure: The operation failed internally
Driver info
/xyz/openbmc_project/software/enumerate
{
"/xyz/openbmc_project/software/136cf504": {
"Activation": "xyz.openbmc_project.Software.Activation.Activations.Active",
"ExtendedVersion": "op-build-v1.17-210-gbabb528,buildroot-2017.05-93-g9b91216,skiboot-v5.7,hostboot-f523eaa,linux-4.12.1-openpower1-p8927fdf,petitboot-v1.5.1-pce8abef,machine-xml-5575e7e,occ-ca84830,hostboot-binaries-c24fccd,capp-ucode-9c73e9f,sbe-02021c6-p6a0f00f",
"Path": "",
"Priority": 0,
"Purpose": "xyz.openbmc_project.Software.Version.VersionPurpose.Host",
"RequestedActivation": "xyz.openbmc_project.Software.Activation.RequestedActivations.None",
"Version": "IBM-witherspoon-sequoia-ibm-OP9_v1.17_1.87"
},
"/xyz/openbmc_project/software/3c88ccca": {
"Activation": "xyz.openbmc_project.Software.Activation.Activations.Active",
"Path": "",
"Purpose": "xyz.openbmc_project.Software.Version.VersionPurpose.BMC",
"RequestedActivation": "xyz.openbmc_project.Software.Activation.RequestedActivations.None",
"Version": "v1.99.8-208-g4ee6757"
}
}
root@witherspoon:~# uname -a
Linux witherspoon 4.10.17-baeb50beb784ac5993d2bfb5d06d909971b60506 #1 Wed Aug 9 20:28:09 UTC 2017 armv6l GNU/Linux
root@witherspoon:~#
In the MRW which is in the build the IPMI_SENSOR_TYPE of occ_active_sensor is 0x07, it was 0x09 and 0x07 is for the functional/present status of processor and its children. that change created this failure sending to Matt Spinler.
`
<attribute>
<id>IPMI_SENSOR_TYPE</id>
<default>0x07</default>
</attribute>
`
@spinler - are you aware of this change?
Per discussion in our meeting this morning, the ipmid code needs to support this (basically 2 different sensors that map to different dbus objects with the same sensor type).
Per Dhruv:
if we will have different kind of messages coming under one message type, need to support path and service interface per interface instead of per sensor type
some changes needed in YAML, MRW parser and mako code generator to do that
I agree with Dhruv's planned solution to generate update methods per interface instead of per sensor type. I can make the necessary changes today and put for review.
@nasamuffin I suppose the sensor type that's just mapped to a single "update" interface today should change to a list. We realized today that we have sensor types that map to more than one d-bus object.
Aug 12 : coding in progress.
Aug 13 : Code up for review - https://gerrit.openbmc-project.xyz/#/q/status:open+AND+topic:2130.
Aug 14 : Need peer reviews from Tom and Andrew. Andrew did a review yesterday, which I have addressed.
Aug 14 : Peer reviews completed. Ready for merge review.
https://gerrit.openbmc-project.xyz/5972 ipmi sensors: fix d-bus mappings in input yaml
Resolves #2130 xyz.openbmc_project.Common.Error.InternalFailure: Support sensor type to multiple dbus objects mapping
These commits resolve the issue : https://gerrit.openbmc-project.xyz/#/q/topic:2130.
Most helpful comment
I agree with Dhruv's planned solution to generate update methods per interface instead of per sensor type. I can make the necessary changes today and put for review.