Redfish Dump Service Proposal

[Bills, Jason M]

On 1/8/2020 12:04 PM, Brad Bishop wrote:
> 
> 
>> On Dec 13, 2019, at 3:01 PM, Bills, Jason M <jason.m.bills at linux.intel.com> wrote:
>>
>> I like this as well.  I'm trying to support a CPU crashdump that would fit perfectly with this proposal.
> 
> Hi Jason
> 
> Could you say a few words about how your crash dump service works?  I’m asking because Dhruv is working on an implementation of this proposal:

Sure.

I have a service called host-error-monitor that watches for error 
signals from the host.  When a CPU fatal error occurs, the 
host-error-monitor triggers a crashdump from the crashdump service.

The crashdump service itself is very minimal today.  It has two trigger 
methods on DBus.  One is to trigger a log for a real error that may need 
to be stored on the BMC.  The other is to trigger a manual log that does 
not need to persist.

When triggered, the BMC reads the crash data from the CPU using PECI. 
After a log has been completed, it is added to DBus as a new object with 
a 'Log' property which holds the contents of the log as a string.

The host-error-monitor source is shared here: 
https://github.com/Intel-BMC/host-error-monitor.
The crashdump source is not currently licensed for public access.

> 
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/28260
> 
> Right now it looks pretty POWER-centric but depending on how your code works I’m wondering which makes more sense:
> 
> 1 - a single implementation with —-enable-power —-enable-x86 type configure options.
> 
> -or-
> 
> 2 - two completely different implementations with the same dbus interfaces.
I think this is probably the simplest approach.  It will allow us to 
standardize the Redfish interface without worrying about the actual log 
collection.

I also think we can move from this toward option 1 if we find a lot of 
commonalities in the future.

> 
> thoughts?
>