Re: [PATCH 0/2] kdump: Enter 2nd kernel with BSP for enabling multipleCPUs
From: HATAYAMA Daisuke
Date: Fri Apr 19 2013 - 04:45:51 EST
(2013/04/18 20:41), Petr Tesarik wrote:
On Mon, 16 Apr 2012 11:21:28 +0900
HATAYAMA Daisuke <d.hatayama@xxxxxxxxxxxxxx> wrote:
Currently, booting up 2nd kernel with multiple CPUs fails in most
cases since it enters 2nd kernel with AP if the crash happens on the
AP. The problem is to signal startup IPI from AP to BSP. Typical
result of the operation I saw is the machine hanging during the 2nd
kernel boot.
To solve this issue, always enter 2nd kernel with BSP. To do this, I
modify logic for shooting down CPUs. I use simple existing logic only
in this mechanism, not complicating crash path to machine_kexec().
These patches looked pretty good. I seem to recall that Fenghua (from
Intel) had an alternative solution for booting from AP. Unfortunately I
can't find his mails in my kexec mailbox...
Anyway, what's the latest upstream status?
It's still in experimental state.
The patch itself was nacked by Erick since switching the CPU that
entered 2nd kenrel through NMI reduced reliability of kdump.
At the discussion of my 2nd patch set that tried to reset BSP flag at
boot on the 2nd kernel, Erick suggested that BSP flag could be changed
at runtime and then behaviour when INIT was received varied and first we
should discuss how unsetting BSP flag affects system.
I'm now going in this direction and the patch I posted a month ago is:
[PATCH] x86, apic: Add unset_bsp parameter to unset BSP flag at boot time
https://lkml.org/lkml/2013/3/18/107
According to Fenghua, some kind of firmware assumes that BSP flag is
being kept throughout system is running. I have yet to see difference of
behaviour when unsetting BSP flag on top of the patch on my machine. I
think this is system dependent and it might be better to assign each
user to decide whether to unset BSP flag or not.
BTW, the work of software cpu hotplug for BSP by Fenghua is orthogonal
to my case. His work is for system including firmware that is affected
if BSP flag is unset and assumes healthy system that cpu#0 is always
BSP. On the other hand, our case is for crash kernel and we can no
longer assume cpu#0 is BSP and can no longer use NMI to wake up other
CPUs since we cannot use logic that depends on the state of CPUs
sleeping in the 1st kernel.
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/