Proposal for caching/buffering POST codes list for one boot process.

Wang, Kuiying kuiying.wang at intel.com
Fri Aug 24 17:28:55 AEST 2018


Hi Kun,
Current implementation of phosphor-host-postd just publish one POST code to DBus, but no caching/buffering logic.
So other module cannot get a list of POST code for current/previous boot process.
So there is a proposal to do that which could benefit issue debugging and analysis.


1.      Define 2 properties in Raw.interface.yaml (https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/Boot/Raw.interface.yaml )
properties:
    - name: Value
      type: uint64
      description: >
          The POST code value.
    - name: PrePostCodes
      type: variant[uint32, uint64]
      description: >
          The POST code list of previous boot process.
          The fist uint32 is the time stamp the post code;
          the second uint64 is the post code value.
    - name: CurrPostCodes
      type: variant[uint32, uint64]
      description: >
          The POST code list of current boot process.
          The fist uint32 is the time stamp the post code;
          the second uint64 is the post code value.

2.      Save post code to CurrPostCodes list together w/ timestamp in PostCodeEventHandler function.

https://github.com/openbmc/phosphor-host-postd/blob/master/main.cpp#L99

3.      When detect host power off, copy CurrPostCodes to PrePostCodes and clean CurrPostCodes in host state manager

https://github.com/openbmc/phosphor-state-manager/blob/master/host_state_manager.cpp#L225

BTW: we could implement an IPMI command to get current/previous post codes remotely.

Thanks,
Kuiying.

From: Kun Yi [mailto:kun.yi.731 at gmail.com]
Sent: Wednesday, August 22, 2018 12:36 AM
To: Wang, Kuiying <kuiying.wang at intel.com>
Cc: Li, Yong B <yong.b.li at intel.com>
Subject: Re: about post code

Hi Kuiying,

Yes, only the current POST code is published on DBus. The idea of caching/buffering more POST codes on the DBus server side is definitely interesting. It would require some thoughts on the DBus interface. If you have some thoughts, you are welcome to email the openbmc mailing list for a discussion.

With that said, it's not hard to implement a listener client that caches the POST codes received and stream them to log/file/network. The listener can also talk to the host Power control interface to interpret which POST codes these are for.

Thanks,
Kun

On Mon, Aug 20, 2018 at 2:51 AM Wang, Kuiying <kuiying.wang at intel.com<mailto:kuiying.wang at intel.com>> wrote:
Hi Kunyi,
According to the Raw.interface.yaml definition, and existing implementation, only current one post code is posted to dbus, right?
Do you plan to save all the post codes(and the timestamp for each) for previous boot process and current process?


Thanks,
Kuiying.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180824/56e69ab7/attachment-0001.html>


More information about the openbmc mailing list