dbus-sensor: setting the upper non-critical(unc) threshold value smaller than reading value would get 3 logs ( assert log, de-assert log and then assert log)

Wed Feb 26 20:29:02 AEDT 2020

Hi James,

  We offer a proposal to fix this bug. The bug is about that if we set the upper non-critical (unc) threshold value smaller than reading value, we should get only one assert log but we got 3 logs (assert log, de-assert log and then assert log). We expect the result is that we can change threshold value property on Dbus (xyz.openbmc_project.EntityManager service and xyz.openbmc_project.IpmbSensor service) and get assert/deassert sel log when we trigger/untrigger the threshold mechanism.

  Our proposal is about that modify struct sensor's "objectType" member define from "xyz.openbmc_project.Configuration.ExitAirTemp" to "xyz.openbmc_project.Configuration.IpmbSensor". Add a new member (bool alarmvalue) in struct Threshold in threshold.hpp. Keeping update alarmvalue when process (ipmbsensor) in function of checkThresholds(). When modifying the threshold value and then process going into function of creatsensor() again. Rewrite the sensor value and alarmvalue into global struct sensor after global struct sensor initialization. What do you think about our proposal ? Would you accept our proposal ? Please let us know if you have any questions. Thanks for your reply!

[cid:image003.png at 01D5ECCA.3ACBEE90]

Engineer

Storage Firmware

Development Dept.

Firmware Development Div.

Wiwynn Corporation

Tel: +886-2-6614-7549

E-mail: Max_Lai at wiwynn.com

-----Original Message-----

From: James Feist <james.feist at linux.intel.com>

Sent: Wednesday, February 26, 2020 1:33 AM

To: Max Lai/WYHQ/Wiwynn <Max_Lai at wiwynn.com>

Cc: openbmc at lists.ozlabs.org; LF_OpenBMC.WYHQ.Wiwynn <LF_OpenBMC.WYHQ.Wiwynn at Wiwynn.com>

Subject: Re: dbus-sensor: setting the upper non-critical(unc) threshold value smaller than reading value would get 3 logs ( assert log, de-assert log and then assert log)

On 2/24/20 5:29 PM, Max Lai/WYHQ/Wiwynn wrote:

> Hi James,

>

> Sorry for I offered the wrong information. The last mail this sentence

> "struct sensor's "objectType" member which was set

> "xyz.openbmc_project.Configuration.ExitAirTemp" was different than our

> "xyz.openbmc_project.EntityManager"." is *wrong*. The

> *correct*information is "struct sensor's "objectType" member which was

> set "xyz.openbmc_project.Configuration.ExitAirTemp" was different than

> our "*xyz.openbmc_project.Configuration.IpmbSensor*". The different is

> between "xyz.openbmc_project.Configuration.*ExitAirTemp*" and

> "xyz.openbmc_project.Configuration.*IpmbSensor*".

That looks like a bug.. I'll look into it. I think it's a copy paste error.

---------------------------------------------------------------------------------------------------------------------------------------------------------------
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. 
Any unauthorized review, use, copying or distribution of this email or the content of this email is strictly prohibited.
If you are not the intended recipient, you may reply to the sender and should delete this e-mail immediately.
---------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200226/455ba780/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 71864 bytes
Desc: image003.png
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200226/455ba780/attachment-0001.png>