Implement IPMI POH functionality

[Alexander Amelkin]

27.03.2018 04:41, Emily Shaffer wrote:
>
>
> On Mon, Mar 26, 2018 at 5:00 AM Ratan Gupta
> <ratagupt at linux.vnet.ibm.com <mailto:ratagupt at linux.vnet.ibm.com>> wrote:
>
>     Hi,
>
>     I would be explaining a rough idea of how we plan to go about,
>     This is related to https://github.com/openbmc/openbmc/issues/2979
>
>     Please share your thoughts and feedback on this proposal.
>
>     =>we were planning to add the property in the chassis interface
>        which tells that since how many hours chassis was powered on.
>
>     =>This property gets updated by internal timer which wakes up after
>        an hour and updates this property if chassis is powered on.
>
>         1) Should we set the uptime to 0 if chassis state has been
>     transitioned from
>         PowerOn-->PowerOff
>
>                                   or
>
>         2) Don't update this property for the chassis power off
>     duration and
>     update
>         this property when the chassis state changes to PowerOn.
>
>         What is community view on this?
>
>
> IMO, it depends on whether clients might be using this uptime to
> determine whether the host is on now; or maybe whether they might need
> to capture the latest uptime during some crash log that begins after
> the host goes down.  My gut feeling is that it's correct to set it to
> zero when it powers off, and start incrementing it again starting when
> it powers on.  But I also suppose it's not feasible to use uptime to
> determine current host state, if the value is stored in hours, since
> it would be almost one full hour before the value could report the
> host as "on"....
>
> Is there a use case where someone might want to read the previous
> uptime, while the host is still down?
I believe, we must follow the IPMI specification, which clearly states
in section 1.7.28 that the POH counter is:

"to return a counter value proportional to the system operating (S0)
power-on hours"

It looks quite clear to me that this is similar to a car mileage meter.
That is, a means to identify when it's time to do some servicing and/or
track warranty.

The note in section 28.14 further backs my understanding and clarifies
the matter:

======
Note that in a power-managed system, the definition of ‘powered up’ can
be somewhat ambiguous. The definition
used here is that the power-on hours shall accumulate whenever the
system is in the operational (S0) state. An
implementation may elect to increment power-on hours in the S1 and S2
states as well.

‘Clear’ or ‘Set’ commands are not specified for this counter. This is
because the counter is most typically used for
warranty tracking or replacement purposes where changing or clearing the
counter would defeat the purpose.
======

Hence, we need to elect whether or not we want to count S1 and S2 states
(whatever they are called for POWER), but there shall be no doubt that
the value is cumulative and must not be reset to zero.

P.S. I must say that I often see how the community is trying to reinvent
IPMI without reading the specifications. I believe it is a very wrong
approach, and I implore you all to first try to find the answer in the
IPMI specification, and only when the answer can not be found, turn to
other implementations like MegaRAC or anything.

Sincerely,
Alexander.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180328/1c78a698/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180328/1c78a698/attachment.sig>