linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 1/3] powerpc: do not call ppc_md.panic in panic notifier if fadump not used
Date: Wed, 5 Jul 2017 10:16:50 +1000	[thread overview]
Message-ID: <20170705101636.1ec6ab87@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <87o9szydjd.fsf@concordia.ellerman.id.au>

On Wed, 05 Jul 2017 09:42:46 +1000
Michael Ellerman <mpe@ellerman.id.au> wrote:

> Nicholas Piggin <npiggin@gmail.com> writes:
> > diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> > index 94a948207cd2..39ba09965b04 100644
> > --- a/arch/powerpc/kernel/setup-common.c
> > +++ b/arch/powerpc/kernel/setup-common.c
> > @@ -707,12 +707,15 @@ EXPORT_SYMBOL(check_legacy_ioport);
> >  static int ppc_panic_event(struct notifier_block *this,
> >                               unsigned long event, void *ptr)
> >  {
> > -	/*
> > -	 * If firmware-assisted dump has been registered then trigger
> > -	 * firmware-assisted dump and let firmware handle everything else.
> > -	 */
> > -	crash_fadump(NULL, ptr);
> > -	ppc_md.panic(ptr);  /* May not return */
> > +	if (is_fadump_active()) {
> > +		/*
> > +		 * If firmware-assisted dump has been registered then trigger
> > +		 * firmware-assisted dump and let firmware handle everything
> > +		 * else.
> > +		 */
> > +		crash_fadump(NULL, ptr);  
> 
> As Mahesh pointed out the check for fadump active is not correct.

Yep, I misread that code.

> 
> > +		ppc_md.panic(ptr);  /* May not return */  
> 
> But I wonder if this is the real problem?
> 
> AFAICS we only have two users of ppc_md.panic(), ps3 and pseries.
> 
> At least on ps3 it has nothing to do with fadump, so skipping it like
> you've done is not right.

But the call has to do with fadump -- at least that's what the comment
implies. ps3 does not want to panic here (it's .panic is just a hang).
It wants to go via the normal panic path and flush printk buffers etc.

> On pseries it uses rtas_os_term() which tells the HV that we "terminated
> normal operation", unless you're doing fadump it's supposed to return
> and shouldn't stop the regular panic path. Though maybe that's not true
> in practice.
> 
> It sounds like what we need to do is have a look at the panic flow and
> decide whether ppc_md.panic is useful at all, and if so is it called in
> the right place.

Yeah I would say you're probably right. The panic handling could possibly
go into the fadump code itself too, if it's relatively common across all
platforms that use it. It can register its own panic handler, no need for
this generic one.

Thanks,
Nick

  reply	other threads:[~2017-07-05  0:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-04 10:09 [PATCH 0/3] sreset debugging improvements Nicholas Piggin
2017-07-04 10:09 ` [PATCH 1/3] powerpc: do not call ppc_md.panic in panic notifier if fadump not used Nicholas Piggin
2017-07-04 16:52   ` Mahesh Jagannath Salgaonkar
2017-07-04 23:42   ` Michael Ellerman
2017-07-05  0:16     ` Nicholas Piggin [this message]
2017-07-04 10:09 ` [PATCH 2/3] powerpc/pseries/le: work around a firmware quirk Nicholas Piggin
2017-07-04 10:09 ` [PATCH 3/3] powerpc: do not send system reset request through the oops path Nicholas Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170705101636.1ec6ab87@roar.ozlabs.ibm.com \
    --to=npiggin@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).