From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Michael Neuling <mikey@neuling.org>,
gregkh@linuxfoundation.org, LKML <linux-kernel@vger.kernel.org>,
Milton Miller <miltonm@bga.com>,
linux-next@vger.kernel.org,
ppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: Boot failure with next-20120208
Date: Sat, 24 Mar 2012 09:18:10 +1100 [thread overview]
Message-ID: <1332541090.2882.14.camel@pasglop> (raw)
In-Reply-To: <4F6CCDDC.5000802@linux.intel.com>
On Fri, 2012-03-23 at 12:24 -0700, Arjan van de Ven wrote:
> well yeah, PPC is throwing things in the spanner
>
> we're now working on an x86-only patch with basically the same
> improvement, but done in a way that does not touch the other
> architectures
>
> so by all means drop the patch
Or maybe make an arch flag to enable the behaviour ? I can have a look
at the problem & maybe even fix it next week (it's been under my radar
for some reason so far), but I know at least of a few places where we
have that sort of assumptions about the bringup of boot CPUs.
For example, on Apple G5s, we don't support real hotplug, so the hot
unplug path just puts them in a linux-controlled sleep loop. So the
early boot time bringup is different from the hotplug path.
Among others, it needs access to things like i2c to synchronize the time
bases of the CPUs being brought up and we "release" that resource at the
end of the bringup.
So that needs fixing a way or another (and it's non trivial as other
drivers might try to get a lock on that i2c bus).
I'm sure I have a few other places with similar assumptions. And I
wouldn't be surprised if other architectures do as well :-)
So while your patch is a good / worthwhile idea, I think we need a bit
more time to sort things out before it can be applied.
(BTW. Arjan, can you send me privately your latest version of that
patch, for some reason I don't seem to be able to put my hand on it).
Cheers,
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Michael Neuling <mikey@neuling.org>,
gregkh@linuxfoundation.org, LKML <linux-kernel@vger.kernel.org>,
Milton Miller <miltonm@bga.com>,
linux-next@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
ppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: Boot failure with next-20120208
Date: Sat, 24 Mar 2012 09:18:10 +1100 [thread overview]
Message-ID: <1332541090.2882.14.camel@pasglop> (raw)
In-Reply-To: <4F6CCDDC.5000802@linux.intel.com>
On Fri, 2012-03-23 at 12:24 -0700, Arjan van de Ven wrote:
> well yeah, PPC is throwing things in the spanner
>
> we're now working on an x86-only patch with basically the same
> improvement, but done in a way that does not touch the other
> architectures
>
> so by all means drop the patch
Or maybe make an arch flag to enable the behaviour ? I can have a look
at the problem & maybe even fix it next week (it's been under my radar
for some reason so far), but I know at least of a few places where we
have that sort of assumptions about the bringup of boot CPUs.
For example, on Apple G5s, we don't support real hotplug, so the hot
unplug path just puts them in a linux-controlled sleep loop. So the
early boot time bringup is different from the hotplug path.
Among others, it needs access to things like i2c to synchronize the time
bases of the CPUs being brought up and we "release" that resource at the
end of the bringup.
So that needs fixing a way or another (and it's non trivial as other
drivers might try to get a lock on that i2c bus).
I'm sure I have a few other places with similar assumptions. And I
wouldn't be surprised if other architectures do as well :-)
So while your patch is a good / worthwhile idea, I think we need a bit
more time to sort things out before it can be applied.
(BTW. Arjan, can you send me privately your latest version of that
patch, for some reason I don't seem to be able to put my hand on it).
Cheers,
Ben.
next prev parent reply other threads:[~2012-03-23 22:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-12 0:38 Boot failure with next-20120208 Stephen Rothwell
2012-02-12 0:38 ` Stephen Rothwell
2012-02-13 3:04 ` Michael Neuling
2012-02-13 3:04 ` Michael Neuling
2012-02-13 5:47 ` Stephen Rothwell
2012-02-13 5:47 ` Stephen Rothwell
2012-02-13 14:18 ` Arjan van de Ven
2012-02-13 14:18 ` Arjan van de Ven
2012-02-13 20:05 ` Andrew Morton
2012-02-13 20:05 ` Andrew Morton
2012-02-13 20:16 ` Arjan van de Ven
2012-02-13 20:16 ` Arjan van de Ven
2012-03-23 19:22 ` Andrew Morton
2012-03-23 19:22 ` Andrew Morton
2012-03-23 19:24 ` Arjan van de Ven
2012-03-23 19:24 ` Arjan van de Ven
2012-03-23 22:18 ` Benjamin Herrenschmidt [this message]
2012-03-23 22:18 ` Benjamin Herrenschmidt
2012-02-13 21:42 ` Srivatsa S. Bhat
2012-02-13 21:42 ` 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=1332541090.2882.14.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mikey@neuling.org \
--cc=miltonm@bga.com \
--cc=sfr@canb.auug.org.au \
/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.