Redfish Dump Service Proposal
Bills, Jason M
jason.m.bills at linux.intel.com
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 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:
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.
> 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.
More information about the openbmc