From: Jack Steiner <steiner@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: Sending cpu 0 back to SAL slave loop
Date: Sat, 07 Oct 2006 02:16:59 +0000 [thread overview]
Message-ID: <20061007021659.GA23895@sgi.com> (raw)
In-Reply-To: <20061006203909.GA6500@sgi.com>
On Fri, Oct 06, 2006 at 02:44:43PM -0600, Matthew Wilcox wrote:
> On Fri, Oct 06, 2006 at 03:39:10PM -0500, Jack Steiner wrote:
> > For kexec, it is ESSENTIAL that all cpus except for the one doing
> > the kexec be returned to the SAL slave loop. If this is not done, our
> > chipset will misdirect IO interrupts on the newly exec'ed kernel.
>
> Could you do an IPI call to have CPU 0 do the kexec and have the CPU
> that sent the IPI fall into the SAL slave loop instead?
Yes, that seems ok, too. One endcase that must be covered is the
case where where 1) cpu >0 panics and, 2) cpu 0 is looping with interrupts
disabled - perhaps waiting on a lock held by the panic'ing cpu.
In this case, the panic'ing cpu must send an NMI interrupt to cpu 0
to cause it to do the kexec. Not sure but I think this can be made to work.
Hmmmmm. Another case that is more difficult to handle is a failure
where an MCA has occurred & cpu 0 is in the SAL rendez slave loop.
Kexec will have to bring cpu out of the rendez slave loop & cause it
to kexec the new kernel. Is this possible???
I like the NMI approach for the general case where you are kexec'ing
a new kernel - not a crashdump kernel. We have some dependencies on
the boot cpu not changing.
-- jack
next prev parent reply other threads:[~2006-10-07 2:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-06 20:39 Sending cpu 0 back to SAL slave loop Jack Steiner
2006-10-06 20:44 ` Matthew Wilcox
2006-10-07 2:16 ` Jack Steiner [this message]
2006-10-08 5:40 ` Zou, Nanhai
2006-10-08 7:37 ` Keith Owens
2006-10-09 15:09 ` Jack Steiner
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=20061007021659.GA23895@sgi.com \
--to=steiner@sgi.com \
--cc=linux-ia64@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.