From: Laurent Vivier <lvivier@redhat.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
dgibson@redhat.com, thuth@redhat.com
Subject: Re: [PATCH] powerpc: on crash, kexec'ed kernel needs all CPUs are online
Date: Fri, 16 Oct 2015 09:48:21 +0200 [thread overview]
Message-ID: <5620ABC5.6060300@redhat.com> (raw)
In-Reply-To: <1444961690.28419.1.camel@ellerman.id.au>
On 16/10/2015 04:14, Michael Ellerman wrote:
> On Thu, 2015-10-15 at 21:00 +0200, Laurent Vivier wrote:
>> On kexec, all secondary offline CPUs are onlined before
>> starting the new kernel, this is not done in the case of kdump.
>>
>> If kdump is configured and a kernel crash occurs whereas
>> some secondaries CPUs are offline (SMT=off),
>> the new kernel is not able to start them and displays some
>> "Processor X is stuck.".
>
> Do we know why they are stuck?
Yes, we know :)
On the crash, as the CPUs are offline, kernel doesn't call
opal_return_cpu(), so for OPAL all these CPU are always in the kernel.
When the new kernel starts, it call s opal_query_cpu_status() to know
which CPUs are available. As they were not returned to OPAL these CPUs
are not available, but as the kernel logic relies on the fact they must
be available (the logic is SMT is on), it is waiting for their starting
and wait for ever...
When the kernel starts, all secondary processors are started by a call
for each of them of __cpu_up():
__cpu_up()
...
cpu_callin_map[cpu] = 0;
...
rc = smp_ops->kick_cpu(cpu);
...wait...
if (!cpu_callin_map[cpu]) {
printk(KERN_ERR "Processor %u is stuck.\n", cpu);
...
on powernv, kick_cpu() is pnv_smp_kick_cpu():
pnv_smp_kick_cpu()
...
unsigned long start_here =
__pa(ppc_function_entry(generic_secondary_smp_init));
...
/*
* Already started, just kick it, probably coming from
* kexec and spinning
*/
rc = opal_query_cpu_status(pcpu, &status);
...
if (status == OPAL_THREAD_STARTED)
goto kick;
...
rc = opal_start_cpu(pcpu, start_here);
...
kick:
...
generic_secondary_smp_init() is a function in assembly language that
calls in the end start_secondary() :
start_secondary()
...
cpu_callin_map[cpu] = 1;
...
So processors are stucked because start_secondary() is never called.
start_secondary() is never called because OPAL cpu status is
OPAL_THREAD_STARTED.
Secondary CPUs are in "OPAL_THREAD_STARTED" state because they have not
been returned to OPAL on crash.
CPUs are returned to OPAL by pnv_kexec_cpu_down() which is called by
crash_ipi_callback() (for secondary cpus)... except if the cpu is not
online.
As the CPUs are offline, they are not returned to OPAL, and then kernel
can't restart them.
> I really don't like this fix. The reason we're doing a kdump is because the
> first kernel has panicked, possibly with locks held or data structures
> corrupted. Calling cpu_up() then goes and tries to run a bunch of code in the
> crashed kernel, which increases the chance of us just wedging completely.
I agree, but the whole logic of the POWER kernel is we have all the
threads available.
Moreover the kernel parameter "maxcpus" is ignored if it is not a
multiple of thread per core:
...
static int subcore_init(void)
{
if (!cpu_has_feature(CPU_FTR_ARCH_207S))
return 0;
/*
* We need all threads in a core to be present to split/unsplit so
* continue only if max_cpus are aligned to threads_per_core.
*/
if (setup_max_cpus % threads_per_core)
return 0;
...
next prev parent reply other threads:[~2015-10-16 7:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-15 19:00 [PATCH] powerpc: on crash, kexec'ed kernel needs all CPUs are online Laurent Vivier
2015-10-16 0:27 ` kbuild test robot
2015-10-16 2:14 ` Michael Ellerman
2015-10-16 7:48 ` Laurent Vivier [this message]
2015-10-17 2:01 ` Benjamin Herrenschmidt
2015-10-16 2:29 ` David Gibson
2015-10-16 7:57 ` Laurent Vivier
2015-10-17 2:03 ` Benjamin Herrenschmidt
2015-11-04 12:34 ` Hari Bathini
2015-11-04 13:54 ` Laurent Vivier
2015-11-05 1:32 ` David Gibson
2015-11-05 6:59 ` Stewart Smith
2015-11-05 10:23 ` Hari Bathini
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=5620ABC5.6060300@redhat.com \
--to=lvivier@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=dgibson@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=thuth@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 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).