openbmc Digest, Vol 64, Issue 61
Manikandan E
manikandan.e at hcl.com
Fri Dec 25 04:12:04 AEDT 2020
Hi All,
Please ignore my previous mail.
Thanks
Mani.E
________________________________
From: Manikandan E <manikandan.e at hcl.com>
Sent: 24 December 2020 22:37
To: openbmc at lists.ozlabs.org <openbmc at lists.ozlabs.org>
Subject: Re: openbmc Digest, Vol 64, Issue 61
Dear Kotes,
I am not able to change RM in ESS as attached snap issue and raised SSD .
Will update RM after issue is fixed.
Thanks
Mani.E
________________________________
From: openbmc <openbmc-bounces+manikandan.e=hcl.com at lists.ozlabs.org> on behalf of openbmc-request at lists.ozlabs.org <openbmc-request at lists.ozlabs.org>
Sent: 24 December 2020 21:17
To: openbmc at lists.ozlabs.org <openbmc at lists.ozlabs.org>
Subject: openbmc Digest, Vol 64, Issue 61
[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]
Send openbmc mailing list submissions to
openbmc at lists.ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ozlabs.org%2Flistinfo%2Fopenbmc&data=04%7C01%7Cmanikandan.e%40hcl.com%7Cf3a0dcdc61be45d37abe08d8a8236b42%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637444217385303803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VvMdH6QwpLbItcdbbVrEDYfPPCG2OGBBxCC%2FqAb57F8%3D&reserved=0
or, via email, send a message with subject or body 'help' to
openbmc-request at lists.ozlabs.org
You can reach the person managing the list at
openbmc-owner at lists.ozlabs.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openbmc digest..."
Today's Topics:
1. Re: create meta-ampere folder in openbmc repo (Thang Q. Nguyen)
2. Re: Phosphor-hwmon: reduce hwmonio::retries when sensor is
Nonfunctional. (Lei Yu)
3. Re: Phosphor-hwmon: reduce hwmonio::retries when sensor is
Nonfunctional. (Thu Nguyen)
4. peci-pcie CI issues (Andrei Kartashev)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Dec 2020 08:46:47 +0700
From: "Thang Q. Nguyen" <thang at os.amperecomputing.com>
To: Brad Bishop <bradleyb at fuzziesquirrel.com>, OpenBMC Maillist
<openbmc at lists.ozlabs.org>
Subject: Re: create meta-ampere folder in openbmc repo
Message-ID:
<0e2507bc-f8c5-85c4-cd39-4c603a729f4c at os.amperecomputing.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Brad,
Can you help create the meta-ampere folder inside the openbmc repository?
Best Regards,
Thang Q. Nguyen -
On 12/16/20 16:54, Thang Q. Nguyen wrote:
> Hi Brad,
>
> Please help add meta-ampere repository into openbmc as a subtree.
> The meta-ampere repository has been populated with basic bring up code.
>
> Thanks,
> Thang Q. Nguyen
>
------------------------------
Message: 2
Date: Thu, 24 Dec 2020 09:52:29 +0800
From: Lei Yu <yulei.sh at bytedance.com>
To: Thu Nguyen <thu at amperemail.onmicrosoft.com>
Cc: openbmc <openbmc at lists.ozlabs.org>
Subject: Re: Phosphor-hwmon: reduce hwmonio::retries when sensor is
Nonfunctional.
Message-ID:
<CAGm54UEr=jX1jHFYG37BthZ0YoVeqcAtk3NrrFXf=ki7Vfzm5A at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Wed, Dec 23, 2020 at 11:33 PM Thu Nguyen
<thu at amperemail.onmicrosoft.com> wrote:
>
> On 12/16/20 14:33, Thu Nguyen wrote:
> > Hi All,
> >
> >
> > I'm working with Fan sensors on Ampere MtJade platform.
> >
> > In this platform, I have multiple fans which name as FAN3_1, FAN3_2,
> > FAN4_1, FAN4_2, FAN5_1...
> >
> > I added the configuration for those fans in phosphor-hwmon and I also
> > added option "--enable-update-functional-on-fail" in phosphor-hwmon
> > build flag. I'm trying to set fan functional to false when unplug fan.
> >
> > Flash new image to the board, read functional of fans. The time to
> > read dbus property is about 0.05->0.1 seconds:
> >
> > root at mtjade:~# time busctl get-property
> > xyz.openbmc_project.Hwmon-1644477290.Hwmon1
> > /xyz/openbmc_project/sensors/fan_tach/FAN4_2
> > xyz.openbmc_project.State.Decorator.OperationalStatus Functional
> > b true
> >
> > real 0m0.078s
> > user 0m0.002s
> > sys 0m0.032s
> > root at mtjade:~# time busctl get-property
> > xyz.openbmc_project.Hwmon-1644477290.Hwmon1
> > /xyz/openbmc_project/sensors/fan_tach/FAN3_2
> > xyz.openbmc_project.State.Decorator.OperationalStatus Functional
> > b true
> >
> >
> > real 0m0.044s
> > user 0m0.001s
> > sys 0m0.034s
> >
> > After unplug one fan (FAN4_2), I can see that fan functional of FAN4_2
> > is set to false as expected. And functional of others fans keeps
> > true. But the time to get dbus properties of all fans have a huge
> > increasement event in the working fans.
> >
> > ~# time busctl get-property
> > xyz.openbmc_project.Hwmon-1644477290.Hwmon1
> > /xyz/openbmc_project/sensors/fan_tach/FAN4_2
> > xyz.openbmc_project.State.Decorator.OperationalStatus Functional
> > b false
> >
> > real 0m1.189s
> > user 0m0.001s
> > sys 0m0.036s
> >
> > ~# time busctl get-property
> > xyz.openbmc_project.Hwmon-1644477290.Hwmon1
> > /xyz/openbmc_project/sensors/fan_tach/FAN3_2
> > xyz.openbmc_project.State.Decorator.OperationalStatus Functional
> > b true
> >
> > real 0m3.285s
> > user 0m0.010s
> > sys 0m0.028s
> >
> > The "ipmitool sdr type 0x4" commands is also failed because this
> > increasement.
> >
> > ~$ time ipmitool -I lanplus -U root -P 0penBmc -C 17 -H <BMCIP> sdr
> > type 0x4
> > FAN3_1 | 25h | ok | 29.13 | 5100 RPM
> > FAN3_2 | 28h | ok | 29.16 | 4700 RPM
> > FAN4_1 | 2Bh | ns | 29.19 | No Reading
> > FAN4_2 | 2Eh | ns | 29.22 | No Reading
> > FAN5_1 | 31h | ns | 29.25 | No Reading
> > FAN5_2 | 34h | ns | 29.28 | No Reading
> > FAN6_1 | 37h | ns | 29.31 | No Reading
> > FAN6_2 | 3Ah | ns | 29.34 | No Reading
> > FAN7_1 | 3Dh | ns | 29.37 | No Reading
> > FAN7_2 | 40h | ns | 29.40 | No Reading
> > FAN8_1 | 43h | ns | 29.43 | No Reading
> > FAN8_2 | 46h | ns | 29.46 | No Reading
> > PSU0_fan1 | F5h | ns | 29.60 | No Reading
> > PSU1_fan1 | F6h | ns | 29.61 | No Reading
> >
> > real 2m43.704s
> > user 0m0.046s
> > sys 0m0.057s
> >
> > The cause of this increasement is when it failed to read one sensor
> > phosphor-hwmon keep trying to read the sensors with the retry is 10
> > and the 100ms delays between retry times.
> >
> > Should we reduce the retry for non-functional sensors?
When a fan is unplugged, its "Present" property should be false as well.
Maybe you could check that property and skip such fans?
> >
> >
> > Regards.
> >
> > Thu Nguyen
> Hi All,
>
> Any feed back on this?
>
> Thu Nguyen,
>
--
BRs,
Lei YU
------------------------------
Message: 3
Date: Thu, 24 Dec 2020 09:32:14 +0700
From: Thu Nguyen <thu at amperemail.onmicrosoft.com>
To: Lei Yu <yulei.sh at bytedance.com>
Cc: openbmc <openbmc at lists.ozlabs.org>
Subject: Re: Phosphor-hwmon: reduce hwmonio::retries when sensor is
Nonfunctional.
Message-ID:
<2c526c72-bcad-4751-d18b-3b07ffd12964 at amperemail.onmicrosoft.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 12/24/20 08:52, Lei Yu wrote:
> On Wed, Dec 23, 2020 at 11:33 PM Thu Nguyen
> <thu at amperemail.onmicrosoft.com> wrote:
>> On 12/16/20 14:33, Thu Nguyen wrote:
>>> Hi All,
>>>
>>>
>>> I'm working with Fan sensors on Ampere MtJade platform.
>>>
>>> In this platform, I have multiple fans which name as FAN3_1, FAN3_2,
>>> FAN4_1, FAN4_2, FAN5_1...
>>>
>>> I added the configuration for those fans in phosphor-hwmon and I also
>>> added option "--enable-update-functional-on-fail" in phosphor-hwmon
>>> build flag. I'm trying to set fan functional to false when unplug fan.
>>>
>>> Flash new image to the board, read functional of fans. The time to
>>> read dbus property is about 0.05->0.1 seconds:
>>>
>>> root at mtjade:~# time busctl get-property
>>> xyz.openbmc_project.Hwmon-1644477290.Hwmon1
>>> /xyz/openbmc_project/sensors/fan_tach/FAN4_2
>>> xyz.openbmc_project.State.Decorator.OperationalStatus Functional
>>> b true
>>>
>>> real 0m0.078s
>>> user 0m0.002s
>>> sys 0m0.032s
>>> root at mtjade:~# time busctl get-property
>>> xyz.openbmc_project.Hwmon-1644477290.Hwmon1
>>> /xyz/openbmc_project/sensors/fan_tach/FAN3_2
>>> xyz.openbmc_project.State.Decorator.OperationalStatus Functional
>>> b true
>>>
>>>
>>> real 0m0.044s
>>> user 0m0.001s
>>> sys 0m0.034s
>>>
>>> After unplug one fan (FAN4_2), I can see that fan functional of FAN4_2
>>> is set to false as expected. And functional of others fans keeps
>>> true. But the time to get dbus properties of all fans have a huge
>>> increasement event in the working fans.
>>>
>>> ~# time busctl get-property
>>> xyz.openbmc_project.Hwmon-1644477290.Hwmon1
>>> /xyz/openbmc_project/sensors/fan_tach/FAN4_2
>>> xyz.openbmc_project.State.Decorator.OperationalStatus Functional
>>> b false
>>>
>>> real 0m1.189s
>>> user 0m0.001s
>>> sys 0m0.036s
>>>
>>> ~# time busctl get-property
>>> xyz.openbmc_project.Hwmon-1644477290.Hwmon1
>>> /xyz/openbmc_project/sensors/fan_tach/FAN3_2
>>> xyz.openbmc_project.State.Decorator.OperationalStatus Functional
>>> b true
>>>
>>> real 0m3.285s
>>> user 0m0.010s
>>> sys 0m0.028s
>>>
>>> The "ipmitool sdr type 0x4" commands is also failed because this
>>> increasement.
>>>
>>> ~$ time ipmitool -I lanplus -U root -P 0penBmc -C 17 -H <BMCIP> sdr
>>> type 0x4
>>> FAN3_1 | 25h | ok | 29.13 | 5100 RPM
>>> FAN3_2 | 28h | ok | 29.16 | 4700 RPM
>>> FAN4_1 | 2Bh | ns | 29.19 | No Reading
>>> FAN4_2 | 2Eh | ns | 29.22 | No Reading
>>> FAN5_1 | 31h | ns | 29.25 | No Reading
>>> FAN5_2 | 34h | ns | 29.28 | No Reading
>>> FAN6_1 | 37h | ns | 29.31 | No Reading
>>> FAN6_2 | 3Ah | ns | 29.34 | No Reading
>>> FAN7_1 | 3Dh | ns | 29.37 | No Reading
>>> FAN7_2 | 40h | ns | 29.40 | No Reading
>>> FAN8_1 | 43h | ns | 29.43 | No Reading
>>> FAN8_2 | 46h | ns | 29.46 | No Reading
>>> PSU0_fan1 | F5h | ns | 29.60 | No Reading
>>> PSU1_fan1 | F6h | ns | 29.61 | No Reading
>>>
>>> real 2m43.704s
>>> user 0m0.046s
>>> sys 0m0.057s
>>>
>>> The cause of this increasement is when it failed to read one sensor
>>> phosphor-hwmon keep trying to read the sensors with the retry is 10
>>> and the 100ms delays between retry times.
>>>
>>> Should we reduce the retry for non-functional sensors?
> When a fan is unplugged, its "Present" property should be false as well.
> Maybe you could check that property and skip such fans?
>
In the sensor Dbus object, we don't have the present property. The
present property is belong to the inventory object of the phosphor-fan.
If using present properties, we have to map the fan sensor name with the
corresponding inventory object. We will break the generic character of
phosphor-hwmon.
As my opinion, for hotplug supporting devices such as fans, we should
not retry when failed to read. Because there are no difference between
the fan sensors are failed to read or the fan sensors are unplugged with
the fan.
Is it reasonable to retry to read the failed sensors after each 0.1
seconds?
>>>
>>> Regards.
>>>
>>> Thu Nguyen
>> Hi All,
>>
>> Any feed back on this?
>>
>> Thu Nguyen,
>>
>
------------------------------
Message: 4
Date: Thu, 24 Dec 2020 18:47:23 +0300
From: Andrei Kartashev <a.kartashev at yadro.com>
To: jason.m.bills <jason.m.bills at linux.intel.com>
Cc: openbmc <openbmc at lists.ozlabs.org>
Subject: peci-pcie CI issues
Message-ID: <6c2c44435e704f6eee95b7e35cbc39ccfae32b62.camel at yadro.com>
Content-Type: text/plain; charset="UTF-8"
Hello Jason,
I push several patches to peci-pcie repo, but looks like CI broken
there. Could you take a look on how to fix CI?
[ 90%] Building CXX object CMakeFiles/peci-pcie.dir/src/peci_pcie.cpp.o
In file included from /usr/local/include/boost/asio/execution.hpp:19,
from /usr/local/include/boost/asio/system_executor.hpp:20,
from /usr/local/include/boost/asio/associated_executor.hpp:22,
from /usr/local/include/boost/asio/detail/bind_handler.hpp:20,
from /usr/local/include/boost/asio/detail/wrapped_handler.hpp:18,
from /usr/local/include/boost/asio/io_context.hpp:23,
from /usr/local/include/boost/asio/io_service.hpp:18,
from /home/jenkins-op/workspace/ci-repository/openbmc/peci-pcie/src/peci_pcie.cpp:22:
/usr/local/include/boost/asio/execution/any_executor.hpp: In static member function ???static const std::type_info& boost::asio::execution::detail::any_executor_base::target_type_void()???:
/usr/local/include/boost/asio/execution/any_executor.hpp:811:23: error: cannot use ???typeid??? with ???-fno-rtti???
811 | return typeid(void);
| ^
/usr/local/include/boost/asio/execution/any_executor.hpp: In static member function ???static const std::type_info& boost::asio::execution::detail::any_executor_base::target_type_ex()???:
/usr/local/include/boost/asio/execution/any_executor.hpp:851:21: error: cannot use ???typeid??? with ???-fno-rtti???
851 | return typeid(Ex);
| ^
--
Best regards,
Andrei Kartashev
End of openbmc Digest, Vol 64, Issue 61
***************************************
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20201224/75f2fa36/attachment-0001.htm>
More information about the openbmc
mailing list