[Skiboot] [PATCH v4] IPMI: Trigger OPAL TI in abort path.

[Oliver O'Halloran]

On Tue, Nov 5, 2019 at 10:02 PM Mahesh Salgaonkar
<mahesh at linux.vnet.ibm.com> wrote:
>
> The current assert/abort implementation for BMC based system invokes cec
> reboot after printing backtrace. This means that BMC never gets notified
> about OPAL crash/termination. This sometimes leads into never ending
> IPL-ing loop if OPAL keeps aborting very early in boot path.
>
> Trigger a software xstop (OPAL TI) to inform BMC about the OPAL
> termination. BMC is capable of catching checkstop signal and facilitate in
> rebooting (IPL-ing) host.
>
> With AutoReboot policy, OpenBMC handles checkstop signals and counts them
> against the reboot counter. In cases where OPAL is crashing before host
> reaches to runtime, OpenBMC will move the system in Quiesced state after 3
> or so attempts of IPL/reboot so that system can be debugged. When OPAL
> triggers software checkstop it causes all the CPU threads to be stooped and
> moved to quiesced state. Hence OPAL don't need to explicitly stop all CPUs
> before calling software xstop.
>
> Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
> ---
> v4:
>  - Remove the unwanted header file include leftover from v2.
> v3:
>  - Trigger software xstop (OPAL TI) instead of attn.
> v2:
>  - Always Quiesce the secondaries in abort path.
>  - Change the attn_supported type to bool.

Patch looks fine, but how have you tested it?

I'm wondering mainly because when debugging checkstops with cronus you
usually need to run "ecmdchip cleanup" before you can read host memory
using getmemproc and friends. I assume the BMC's dump collector is
doing something similar since it needs to deal with "real" checkstops
caused by hardware, but I think it would be good to verify it works
the way we think it does. Even if it doesn't the xstop approach is
better since an attn raised on the 2nd chip won't be propagated to the
first (I checked).

Oliver