Out-of-band SRESET
Ananth N Mavinakayanahalli
ananth at linux.vnet.ibm.com
Fri Mar 17 16:25:15 AEDT 2017
On Thu, Mar 16, 2017 at 10:37:56AM -0500, Patrick Williams wrote:
> On Thu, Mar 16, 2017 at 01:32:52PM +0530, Ananth N Mavinakayanahalli wrote:
> > Hi,
> >
> > One requirement from a OpenPOWER service point-of-view is to be able to
> > trigger an out-of-band SRESET on a unresponsive system. We can then have
> > the necessary plumbing in the host Linux kernel to either drop the
> > machine into a debugger or trigger a dump capture, if configured.
> >
> > On P9, this would translate to a series of SCOM operations for the SBE
> > It would be good to have a REST API defined to cater to this specific
> > purpose.
> >
> > The API should cater to:
> > - SRESET a core
> > - SRESET a chip
> > - SRESET all cores
> >
> > Thoughts?
> >
> > Regards,
> > Ananth
> >
>
> Ananth,
>
> I understand the desire from your end with respect to debugging the
> host. Is there something we can do to model this better from a REST
> perspective to make this less Power-specific? Do other architectures
> also have a "send debug interrupt"?
Any option that says nmi for x86 can apply here, IMO.
> Do you need to SRESET targeting an SMT thread? We will need to come up
> with some kind of identifier for sending the debug interrupts.
For starters, we will be using the SRESET as an unrecoverable entity --
option of last resort. The SRESET all cores will be the most used, but I
can envisage cases where we would need specific cores/threads to be
forced into xmon or such. While it is good to have the design to be able
to accommodate it, targeted SMT thread reset isn't a 'must have' to
begin with.
Ananth
More information about the openbmc
mailing list