From: ebiederm@xmission.com (Eric W. Biederman)
To: Andi Kleen <andi@firstfloor.org>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
linux-kernel@vger.kernel.org, fenghua.yu@intel.com
Subject: Re: [PATCH 2/2] Enter 2nd kernel with BSP
Date: Tue, 24 Apr 2012 03:46:24 -0700 [thread overview]
Message-ID: <m1ipgpo1a7.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20120424080420.GA27374@one.firstfloor.org> (Andi Kleen's message of "Tue, 24 Apr 2012 10:04:20 +0200")
Andi Kleen <andi@firstfloor.org> writes:
>> native_cpu_up avoids to wake up cpu with boot_cpu_physical_apicid, but
>
> Ok so that check needs to go then. I wonder why it is there.
As I remember we had a check to avoid waking up the current cpu
we are running on, and there was something about the value for
the current cpu coming from BIOS tables etc. Because of all of the
silliness in how we get the apicid for the current cpu I seem to
remember the case where we start all of our secondary processors
to periodically regress.
>> the boot_cpu_physical_apicid would be just a boot cpu now, which could
>> be non-BSP on the 2nd kernel; equal to crashing cpu on the 1st
>> kernel. It would need to check explicitly whether a given cpu is BSP
>> or not and this would be better fix here. This is suggested by Eric.
Yes. My two reasons for designing the crash path the way I did was
that we might have offlined/hot-unplugged the boot cpu, or the bootcpu
might have gotten itself into a terrible state. Since we want as much
reliability in kexec on panic we don't bother trying to restore it.
The normal reboot path, and a normal kexec tries to reboot on the boot
cpu primarily because there are a lot of BIOS's out there that if you
talk to them on anything other than the boot cpu they get confused.
Eric
next prev parent reply other threads:[~2012-04-24 10:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-16 2:21 [PATCH 0/2] kdump: Enter 2nd kernel with BSP for enabling multiple CPUs HATAYAMA Daisuke
2012-04-16 2:21 ` HATAYAMA Daisuke
2012-04-16 2:21 ` [PATCH 1/2] Introduce crash ipi helpers to wait for APs to stop HATAYAMA Daisuke
2012-04-16 2:21 ` HATAYAMA Daisuke
2012-04-16 2:21 ` [PATCH 2/2] Enter 2nd kernel with BSP HATAYAMA Daisuke
2012-04-16 2:21 ` HATAYAMA Daisuke
2012-04-23 10:46 ` Andi Kleen
2012-04-23 10:49 ` Andi Kleen
2012-04-24 2:05 ` HATAYAMA Daisuke
2012-04-24 3:04 ` Yu, Fenghua
2012-04-24 8:04 ` Andi Kleen
2012-04-24 10:46 ` Eric W. Biederman [this message]
[not found] ` <beaa8ade-b7af-4e71-b4e0-a418ceb83f1e@email.android.com>
2012-04-16 6:40 ` [PATCH 0/2] kdump: Enter 2nd kernel with BSP for enabling multiple CPUs HATAYAMA Daisuke
2012-04-16 6:40 ` HATAYAMA Daisuke
2012-05-14 8:29 ` Cong Wang
2013-04-18 11:41 ` Petr Tesarik
2013-04-18 11:41 ` Petr Tesarik
2013-04-19 8:45 ` HATAYAMA Daisuke
2013-04-19 8:45 ` HATAYAMA Daisuke
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=m1ipgpo1a7.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=andi@firstfloor.org \
--cc=d.hatayama@jp.fujitsu.com \
--cc=fenghua.yu@intel.com \
--cc=linux-kernel@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.