From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: ego@linux.vnet.ibm.com,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
matt@ozlabs.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, suzuki@in.ibm.com,
ebiederm@xmission.com,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
paulus@samba.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode
Date: Fri, 06 Jun 2014 18:01:16 +0530 [thread overview]
Message-ID: <5391B494.6050908@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140604134108.GA27557@redhat.com>
On 06/04/2014 07:11 PM, Vivek Goyal wrote:
> On Wed, Jun 04, 2014 at 01:58:40AM +0530, Srivatsa S. Bhat wrote:
>> On 05/28/2014 07:01 PM, Vivek Goyal wrote:
>>> On Tue, May 27, 2014 at 04:25:34PM +0530, Srivatsa S. Bhat wrote:
>>>> If we try to perform a kexec when the machine is in ST (Single-Threaded) mode
>>>> (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we
>>>> get the following messages during boot:
>>>>
[...]
>>>> diff --git a/kernel/kexec.c b/kernel/kexec.c
>>>> index c8380ad..28c5706 100644
>>>> --- a/kernel/kexec.c
>>>> +++ b/kernel/kexec.c
>>>> @@ -1683,6 +1683,14 @@ int kernel_kexec(void)
>>>> kexec_in_progress = true;
>>>> kernel_restart_prepare(NULL);
>>>> migrate_to_reboot_cpu();
>>>> +
>>>> + /*
>>>> + * migrate_to_reboot_cpu() disables CPU hotplug assuming that
>>>> + * no further code needs to use CPU hotplug (which is true in
>>>> + * the reboot case). However, the kexec path depends on using
>>>> + * CPU hotplug again; so re-enable it here.
>>>> + */
>>>> + cpu_hotplug_enable();
>>>> printk(KERN_EMERG "Starting new kernel\n");
>>>> machine_shutdown();
>>>
>>> After migrate_to_reboot_cpu(), we are calling machine_shutdown() which
>>> calls disable_nonboot_cpus() and which in turn calls _cpu_down().
>>>
>>
>> Hmm? I see only 'arm' calling disable_nonboot_cpus() from machine_shutdown().
>> None of the other architectures call it. Is that a leftover in arm?
>
> You are right. I did not notice that only arm is doing that. Looks like
> it is calling into some platform code, I am not sure what exactly arm
> does for disabling cpu.
>
> x86 code calls stop_other_cpus() in machine_shutdown() which sends
> REBOOT_VECTOR to other cpus and calls stop_this_cpu() which in turn
> does.
>
> for (;;)
> halt();
>
> IIUC, upon receipt of certain interrupts cpu will come out of halt state.
> Not sure how safe it is from kexec point of view as we will be replacing
> original kernel that means if cpu comes out of halt state it might be
> running some random code.
>
> Eric/hpa might know better the context here and what safeguards us on x86.
>
> So one should not make cpu spin on some code as kexec will change that
> code. It should be some other platform specific mechanism which brings
> cpu in to hlt like state. So that way arm seems to be doing right thing.
>
> I am not sure what powerpc does to stop cpus.
>
powerpc shepherds all CPUs to a safe state, by making them run kexec_smp_down(),
and eventually those CPUs end up calling kexec_wait() in assembly.
Regards,
Srivatsa S. Bhat
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: ego@linux.vnet.ibm.com, matt@ozlabs.org,
mahesh@linux.vnet.ibm.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, suzuki@in.ibm.com,
ebiederm@xmission.com, paulus@samba.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode
Date: Fri, 06 Jun 2014 18:01:16 +0530 [thread overview]
Message-ID: <5391B494.6050908@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140604134108.GA27557@redhat.com>
On 06/04/2014 07:11 PM, Vivek Goyal wrote:
> On Wed, Jun 04, 2014 at 01:58:40AM +0530, Srivatsa S. Bhat wrote:
>> On 05/28/2014 07:01 PM, Vivek Goyal wrote:
>>> On Tue, May 27, 2014 at 04:25:34PM +0530, Srivatsa S. Bhat wrote:
>>>> If we try to perform a kexec when the machine is in ST (Single-Threaded) mode
>>>> (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we
>>>> get the following messages during boot:
>>>>
[...]
>>>> diff --git a/kernel/kexec.c b/kernel/kexec.c
>>>> index c8380ad..28c5706 100644
>>>> --- a/kernel/kexec.c
>>>> +++ b/kernel/kexec.c
>>>> @@ -1683,6 +1683,14 @@ int kernel_kexec(void)
>>>> kexec_in_progress = true;
>>>> kernel_restart_prepare(NULL);
>>>> migrate_to_reboot_cpu();
>>>> +
>>>> + /*
>>>> + * migrate_to_reboot_cpu() disables CPU hotplug assuming that
>>>> + * no further code needs to use CPU hotplug (which is true in
>>>> + * the reboot case). However, the kexec path depends on using
>>>> + * CPU hotplug again; so re-enable it here.
>>>> + */
>>>> + cpu_hotplug_enable();
>>>> printk(KERN_EMERG "Starting new kernel\n");
>>>> machine_shutdown();
>>>
>>> After migrate_to_reboot_cpu(), we are calling machine_shutdown() which
>>> calls disable_nonboot_cpus() and which in turn calls _cpu_down().
>>>
>>
>> Hmm? I see only 'arm' calling disable_nonboot_cpus() from machine_shutdown().
>> None of the other architectures call it. Is that a leftover in arm?
>
> You are right. I did not notice that only arm is doing that. Looks like
> it is calling into some platform code, I am not sure what exactly arm
> does for disabling cpu.
>
> x86 code calls stop_other_cpus() in machine_shutdown() which sends
> REBOOT_VECTOR to other cpus and calls stop_this_cpu() which in turn
> does.
>
> for (;;)
> halt();
>
> IIUC, upon receipt of certain interrupts cpu will come out of halt state.
> Not sure how safe it is from kexec point of view as we will be replacing
> original kernel that means if cpu comes out of halt state it might be
> running some random code.
>
> Eric/hpa might know better the context here and what safeguards us on x86.
>
> So one should not make cpu spin on some code as kexec will change that
> code. It should be some other platform specific mechanism which brings
> cpu in to hlt like state. So that way arm seems to be doing right thing.
>
> I am not sure what powerpc does to stop cpus.
>
powerpc shepherds all CPUs to a safe state, by making them run kexec_smp_down(),
and eventually those CPUs end up calling kexec_wait() in assembly.
Regards,
Srivatsa S. Bhat
WARNING: multiple messages have this Message-ID (diff)
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: ego@linux.vnet.ibm.com, matt@ozlabs.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
suzuki@in.ibm.com, ebiederm@xmission.com,
mahesh@linux.vnet.ibm.com, paulus@samba.org,
linuxppc-dev@lists.ozlabs.org,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH] powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode
Date: Fri, 06 Jun 2014 18:01:16 +0530 [thread overview]
Message-ID: <5391B494.6050908@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140604134108.GA27557@redhat.com>
On 06/04/2014 07:11 PM, Vivek Goyal wrote:
> On Wed, Jun 04, 2014 at 01:58:40AM +0530, Srivatsa S. Bhat wrote:
>> On 05/28/2014 07:01 PM, Vivek Goyal wrote:
>>> On Tue, May 27, 2014 at 04:25:34PM +0530, Srivatsa S. Bhat wrote:
>>>> If we try to perform a kexec when the machine is in ST (Single-Threaded) mode
>>>> (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we
>>>> get the following messages during boot:
>>>>
[...]
>>>> diff --git a/kernel/kexec.c b/kernel/kexec.c
>>>> index c8380ad..28c5706 100644
>>>> --- a/kernel/kexec.c
>>>> +++ b/kernel/kexec.c
>>>> @@ -1683,6 +1683,14 @@ int kernel_kexec(void)
>>>> kexec_in_progress = true;
>>>> kernel_restart_prepare(NULL);
>>>> migrate_to_reboot_cpu();
>>>> +
>>>> + /*
>>>> + * migrate_to_reboot_cpu() disables CPU hotplug assuming that
>>>> + * no further code needs to use CPU hotplug (which is true in
>>>> + * the reboot case). However, the kexec path depends on using
>>>> + * CPU hotplug again; so re-enable it here.
>>>> + */
>>>> + cpu_hotplug_enable();
>>>> printk(KERN_EMERG "Starting new kernel\n");
>>>> machine_shutdown();
>>>
>>> After migrate_to_reboot_cpu(), we are calling machine_shutdown() which
>>> calls disable_nonboot_cpus() and which in turn calls _cpu_down().
>>>
>>
>> Hmm? I see only 'arm' calling disable_nonboot_cpus() from machine_shutdown().
>> None of the other architectures call it. Is that a leftover in arm?
>
> You are right. I did not notice that only arm is doing that. Looks like
> it is calling into some platform code, I am not sure what exactly arm
> does for disabling cpu.
>
> x86 code calls stop_other_cpus() in machine_shutdown() which sends
> REBOOT_VECTOR to other cpus and calls stop_this_cpu() which in turn
> does.
>
> for (;;)
> halt();
>
> IIUC, upon receipt of certain interrupts cpu will come out of halt state.
> Not sure how safe it is from kexec point of view as we will be replacing
> original kernel that means if cpu comes out of halt state it might be
> running some random code.
>
> Eric/hpa might know better the context here and what safeguards us on x86.
>
> So one should not make cpu spin on some code as kexec will change that
> code. It should be some other platform specific mechanism which brings
> cpu in to hlt like state. So that way arm seems to be doing right thing.
>
> I am not sure what powerpc does to stop cpus.
>
powerpc shepherds all CPUs to a safe state, by making them run kexec_smp_down(),
and eventually those CPUs end up calling kexec_wait() in assembly.
Regards,
Srivatsa S. Bhat
next prev parent reply other threads:[~2014-06-06 12:33 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-27 10:55 [PATCH] powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode Srivatsa S. Bhat
2014-05-27 10:55 ` Srivatsa S. Bhat
2014-05-27 10:55 ` Srivatsa S. Bhat
2014-05-28 13:31 ` Vivek Goyal
2014-05-28 13:31 ` Vivek Goyal
2014-05-28 13:31 ` Vivek Goyal
2014-06-03 20:28 ` Srivatsa S. Bhat
2014-06-03 20:28 ` Srivatsa S. Bhat
2014-06-03 20:28 ` Srivatsa S. Bhat
2014-06-03 22:09 ` Benjamin Herrenschmidt
2014-06-03 22:09 ` Benjamin Herrenschmidt
2014-06-03 22:09 ` Benjamin Herrenschmidt
2014-06-04 13:46 ` Vivek Goyal
2014-06-04 13:46 ` Vivek Goyal
2014-06-04 13:46 ` Vivek Goyal
2014-06-06 12:30 ` Srivatsa S. Bhat
2014-06-06 12:30 ` Srivatsa S. Bhat
2014-06-06 12:30 ` Srivatsa S. Bhat
2014-06-06 18:27 ` Vivek Goyal
2014-06-06 18:27 ` Vivek Goyal
2014-06-06 18:27 ` Vivek Goyal
2014-06-06 19:00 ` Srivatsa S. Bhat
2014-06-06 19:00 ` Srivatsa S. Bhat
2014-06-06 19:00 ` Srivatsa S. Bhat
2014-06-06 12:29 ` Srivatsa S. Bhat
2014-06-06 12:29 ` Srivatsa S. Bhat
2014-06-06 12:29 ` Srivatsa S. Bhat
2014-06-06 12:37 ` Srivatsa S. Bhat
2014-06-06 12:37 ` Srivatsa S. Bhat
2014-06-06 12:37 ` Srivatsa S. Bhat
2014-06-06 21:16 ` Srivatsa S. Bhat
2014-06-06 21:16 ` Srivatsa S. Bhat
2014-06-06 21:16 ` Srivatsa S. Bhat
2014-06-12 6:39 ` Joel Stanley
2014-06-12 6:39 ` Joel Stanley
2014-06-12 6:39 ` Joel Stanley
2014-06-12 8:17 ` Srivatsa S. Bhat
2014-06-12 8:17 ` Srivatsa S. Bhat
2014-06-12 8:17 ` Srivatsa S. Bhat
2014-06-04 13:41 ` Vivek Goyal
2014-06-04 13:41 ` Vivek Goyal
2014-06-04 13:41 ` Vivek Goyal
2014-06-06 12:31 ` Srivatsa S. Bhat [this message]
2014-06-06 12:31 ` Srivatsa S. Bhat
2014-06-06 12:31 ` Srivatsa S. Bhat
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=5391B494.6050908@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=ananth@in.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=ebiederm@xmission.com \
--cc=ego@linux.vnet.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=matt@ozlabs.org \
--cc=paulus@samba.org \
--cc=suzuki@in.ibm.com \
--cc=vgoyal@redhat.com \
/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.