Redfish Dump Service Proposal

Bills, Jason M jason.m.bills at
Thu Jan 9 07:42:42 AEDT 2020

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> 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:


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:
The crashdump source is not currently licensed for public access.

> 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 

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

> thoughts?

More information about the openbmc mailing list