From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 2/2] ARM: decouple CPU offlining from reboot/shutdown
Date: Mon, 17 Jun 2013 12:58:53 -0600 [thread overview]
Message-ID: <51BF5C6D.9050806@wwwdotorg.org> (raw)
In-Reply-To: <1371067281-655-2-git-send-email-swarren@wwwdotorg.org>
On 06/12/2013 02:01 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Add comments to machine_shutdown()/halt()/power_off()/restart() that
> describe their purpose and/or requirements re: CPUs being active/not.
>
> In machine_shutdown(), replace the call to smp_send_stop() with a call to
> disable_nonboot_cpus(). This completely disables all but one CPU, thus
> satisfying the requirement that only a single CPU be active for kexec.
> Adjust Kconfig dependencies for this change.
>
> In machine_halt()/power_off()/restart(), call smp_send_stop() directly,
> rather than via machine_shutdown(); these functions don't need to
> completely de-activate all CPUs using hotplug, but rather just quiesce
> them.
>
> Remove smp_kill_cpus(), and its call from smp_send_stop().
> smp_kill_cpus() was indirectly calling smp_ops.cpu_kill() without calling
> smp_ops.cpu_die() on the target CPUs first. At least some implementations
> of smp_ops had issues with this; it caused cpu_kill() to hang on Tegra,
> for example. Since smp_send_stop() is only used for shutdown, halt, and
> power-off, there is no need to attempt any kind of CPU hotplug here.
>
> Adjust Kconfig to reflect that machine_shutdown() (and hence kexec)
> relies upon disable_nonboot_cpus(). However, this alone doesn't guarantee
> that hotplug will work, or even that hotplug is implemented for a
> particular piece of HW that a multi-platform zImage runs on. Hence, add
> error-checking to machine_kexec() to determine whether it did work.
Russell,
The patch which initially triggered the problem [shutdown/reboot hangs
on Tegra] (cf7df37 "reboot: rigrate shutdown/reboot to boot cpu") ended
up going into v3.10; I assumed it was only going into v3.11.
Is it possible to take this patch for v3.10 rather than v3.11? (or is
your git-curr branch for 3.10; that's where your patchd told me this was
applied.)
next prev parent reply other threads:[~2013-06-17 18:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-12 20:01 [PATCH V2 1/2] kexec: return error of machine_kexec() fails Stephen Warren
2013-06-12 20:01 ` [PATCH V2 2/2] ARM: decouple CPU offlining from reboot/shutdown Stephen Warren
2013-06-13 1:58 ` zhangfei gao
2013-06-13 15:05 ` Stephen Warren
2013-06-13 7:45 ` Will Deacon
2013-06-13 14:59 ` Stephen Warren
2013-06-13 17:11 ` Russell King - ARM Linux
2013-06-14 4:53 ` zhangfei gao
2013-06-13 17:10 ` Russell King - ARM Linux
2013-06-17 18:58 ` Stephen Warren [this message]
2013-06-17 19:41 ` Russell King - ARM Linux
2013-06-21 22:41 ` [PATCH V2 1/2] kexec: return error of machine_kexec() fails Stephen Warren
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=51BF5C6D.9050806@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=linux-arm-kernel@lists.infradead.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.