From: Nicholas Piggin <npiggin@gmail.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org,
Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Subject: Re: [PATCH v2 1/3] powerpc/powernv: Always stop secondaries before reboot/shutdown
Date: Sat, 11 Nov 2017 17:00:02 +1100 [thread overview]
Message-ID: <20171111170002.0fcbe5c7@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <87tvy2o0gf.fsf@concordia.ellerman.id.au>
On Fri, 10 Nov 2017 22:08:32 +1100
Michael Ellerman <mpe@ellerman.id.au> wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
>
> > Currently powernv reboot and shutdown requests just leave secondaries
> > to do their own things. This is undesirable because they can trigger
> > any number of watchdogs while waiting for reboot, but also we don't
> > know what else they might be doing, or they might be stuck somewhere
> > causing trouble.
> >
> > The opal scheduled flash update code already ran into watchdog problems
> > due to flashing taking a long time, but it's possible for regular
> > reboots to trigger problems too (this is with watchdog_thresh set to 1,
> > but I have seen it with watchdog_thresh at the default value once too):
> >
> > reboot: Restarting system
> > [ 360.038896709,5] OPAL: Reboot request...
> > Watchdog CPU:0 Hard LOCKUP
> > Watchdog CPU:44 detected Hard LOCKUP other CPUS:16
> > Watchdog CPU:16 Hard LOCKUP
> > watchdog: BUG: soft lockup - CPU#16 stuck for 3s! [swapper/16:0]
> >
> > So remove the special case for flash update, and unconditionally do
> > smp_send_stop before rebooting.
> >
> > Return the CPUs to Linux stop loops rather than OPAL. The reason for
> > this is that the path to firmware is longer, and the CPUs may have
> > been interrupted from firmware, which may cause problems to re-enter
> > it. It's better to put them into a simple spin loop to maximize the
> > chance of a successful reboot.
>
> I always assumed we had to send the CPUs back to OPAL for the flashing
> procedure. Is it OK to leave them in Linux?
According to the comment and changelog
2196c6f1ed66eef23df3b478cfe71661ae83726e
It was added just to keep secondaries from going silly. Vasant, can
you remember details?
Thanks,
Nick
next prev parent reply other threads:[~2017-11-11 6:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-23 8:05 [PATCH v2 0/3] avoid secondary hold spinloop when possible Nicholas Piggin
2017-10-23 8:05 ` [PATCH v2 1/3] powerpc/powernv: Always stop secondaries before reboot/shutdown Nicholas Piggin
2017-11-10 11:08 ` Michael Ellerman
2017-11-11 6:00 ` Nicholas Piggin [this message]
2017-11-12 11:57 ` Michael Ellerman
2017-10-23 8:05 ` [PATCH v2 2/3] powerpc: use NMI IPI for smp_send_stop Nicholas Piggin
2017-10-23 21:05 ` kbuild test robot
2017-10-23 23:15 ` kbuild test robot
2017-10-31 7:43 ` Nicholas Piggin
2017-10-23 8:05 ` [PATCH v2 3/3] powerpc/powernv: Avoid waiting for secondary hold spinloop with OPAL Nicholas Piggin
2017-11-14 11:12 ` [v2, " Michael Ellerman
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=20171111170002.0fcbe5c7@roar.ozlabs.ibm.com \
--to=npiggin@gmail.com \
--cc=hegdevasant@linux.vnet.ibm.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).