Entity Manager error in tiogapass

[Johnathan Mantey]

On 4/27/21 9:54 AM, Ed Tanous wrote:
> On Mon, Apr 26, 2021 at 7:23 PM Lei Yu <yulei.sh at bytedance.com> wrote:
>> On Tue, Apr 27, 2021 at 12:35 AM Johnathan Mantey
>> <johnathanx.mantey at intel.com> wrote:
>>> Jayashree,
>>>
>>> On 4/26/21 9:00 AM, Jayashree D wrote:
>>>> Classification: *Confidential*
>>>>
>>>> Hi Team,
>>>>
>>>> In the latest build, I am facing the below issue in Entity Manager for
>>>> tiogapass.
>>>>
>>>> Already issue has been created in Entity Manager Repo - entity-manager
>>>> terminated by 'std::filesystem::__cxx11::filesystem_error' · Issue #8
>>>> · openbmc/entity-manager (github.com)
>>>> <https://github.com/openbmc/entity-manager/issues/8>
>>>>
>>>> root at tiogapass:~# systemctl status
>>>> xyz.openbmc_project.EntityManager.service -l
>>>>
>>>> ● xyz.openbmc_project.EntityManager.service - Entity Manager
>>>>
>>>>       Loaded: loaded
>>>> (]8;;file://tiogapass/lib/systemd/system/xyz.openbmc_project.EntityManager.service/lib/systemd/system/xyz.openbmc_project.EntityManager.service]8;;;
>>>> enabled; vendor preset: enabled)
>>>>
>>>>       Active: active (running) since Thu 1970-01-01 00:04:10 UTC; 25s ago
>>>>
>>>>      Process: 851 ExecStartPre=/bin/mkdir -p /var/configuration
>>>> (code=exited, status=0/SUCCESS)
>>>>
>>>>      Process: 852 ExecStartPre=/bin/mkdir -p /tmp/overlays
>>>> (code=exited, status=0/SUCCESS)
>>>>
>>>>     Main PID: 853 (entity-manager)
>>>>
>>>>       CGroup: /system.slice/xyz.openbmc_project.EntityManager.service
>>>>
>>>>               └─853 /usr/bin/entity-manager
>>>>
>>>> Jan 01 00:04:09 tiogapass systemd[1]: Starting Entity Manager...
>>>>
>>>> Jan 01 00:04:10 tiogapass systemd[1]: Started Entity Manager.
>>>>
>>>> Jan 01 00:04:27 tiogapass entity-manager[853]: Inventory Added
>>>>
>>>> Jan 01 00:04:27 tiogapass entity-manager[853]: terminate called after
>>>> throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
>>>>
>>>> Jan 01 00:04:27 tiogapass entity-manager[853]:   what():  filesystem
>>>> error: recursive directory iterator cannot open directory: No such
>>>> file or directory [/sys/bus/i2c/devices/i2c-16]
>>>>
>>> Check this portion of src/Overlay.cpp
>>> static bool deviceIsCreated(const std::string& devicePath,
>>>                               std::shared_ptr<uint64_t> bus,
>>>                               std::shared_ptr<uint64_t> address,
>>>                               const bool retrying)
>>>
>>> I placed a comment describing the intent of the directory iterator. I
>>> have not seen the issue described on our systems, nor in QEMU (reported
>>> by another dev), so I'm not able to identify the issue.
>> The issue is reported at
>> https://github.com/openbmc/entity-manager/issues/8, and the commit
>> that introduces the issue is
>> https://github.com/openbmc/entity-manager/commit/9b86787adea3f8f29fac2acbb9fa0f48fbcf244a
>>
>> Could you kindly investigate the exception and see how to make it not crash?
> It sounds like Jonathan isn't able to reproduce.  Do you think you
> could capture the full stack trace from the exception?  Do you have
> anything odd on your systems that would cause the differing behavior?
>
>> --
>> BRs,
>> Lei YU

This may be just wishful thinking....
Looking at the JSON input file for bus 16:
"Bus": 16,
             "Name": "MB_C2_AVA_RTEMP",

Would the recent sdbusplus encoding changes cause an issue?
The "_C2" is going to be translated into something that may be problematic.

Does applying 
https://gerrit.openbmc-project.xyz/c/openbmc/sdbusplus/+/42512 change 
anything?

-- 
Johnathan Mantey
Senior Software Engineer
*azad te**chnology partners*
Contributing to Technology Innovation since 1992
Phone: (503) 712-6764
Email: johnathanx.mantey at intel.com <mailto:johnathanx.mantey at intel.com>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210427/9270d565/attachment.sig>