From: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
To: Stewart Smith <stewart@linux.vnet.ibm.com>, linuxppc-dev@ozlabs.org
Subject: Re: [RFC PATCH] powerpc/kexec: Wait 1s for secondaries to enter OPAL
Date: Tue, 28 Jul 2015 16:13:29 +1000 [thread overview]
Message-ID: <55B71D89.7000308@au1.ibm.com> (raw)
In-Reply-To: <m3r3nukut9.fsf@oc8180480414.ibm.com>
On 27/07/15 15:56, Stewart Smith wrote:
> Samuel Mendoza-Jonas <sam.mj@au1.ibm.com> writes:
>> Always include a timeout when waiting for secondary cpus to enter OPAL
>> in the kexec path, rather than only when crashing.
>
> This *sounds* reasonable... but I wonder what actual worse case could
> be and why we'd get stuck too long waiting for things?
>
> What was the original bug/problem that inspired this patch?
>
> and is 1s enough?
"It sounds reasonable" was more or less the inspiration :)
While I was going over some of the code relating to the previous kexec
fix with Ben he pointed this out and suggested there wasn't
much of a reason to differentiate between a crashing/non-crashing
cpu as far as the timeout goes - if we're not 'crashing' we still
don't want to spin forever.
I'll let Ben comment on whether 1s per cpu is enough.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
-----------
LTC Ozlabs
IBM
next prev parent reply other threads:[~2015-07-28 6:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 5:54 [RFC PATCH] powerpc/kexec: Wait 1s for secondaries to enter OPAL Samuel Mendoza-Jonas
2015-07-27 5:56 ` Stewart Smith
2015-07-28 6:13 ` Samuel Mendoza-Jonas [this message]
2015-07-28 9:58 ` Benjamin Herrenschmidt
2015-07-29 7:24 ` Stewart Smith
2015-10-12 11:21 ` [RFC] " Michael Ellerman
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=55B71D89.7000308@au1.ibm.com \
--to=sam.mj@au1.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=stewart@linux.vnet.ibm.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.