On Fri, 2015-07-24 at 22:30 -0700, Jonathan Toppins wrote:
> We have been seeing our powerpc based systems boot with only cpu0 being brought
> online, which seemed odd since these are dual core (P2020) systems. After some
> investigation and testing it appears the commit below introduced in v3.2.61
> causes the problem:
>
> commit 335a4d5ba599428c32e6bdf726cd7f20553220a9
> Author: Michael Neuling <mikey@xxxxxxxxxxx>
> Date: Fri Jun 6 14:28:51 2014 +1000
>
> powerpc: Don't setup CPUs with bad status
>
> commit 59a53afe70fd530040bdc69581f03d880157f15a upstream.
>
> The above commit doesn't take into account ePAPR spin-tables and was later
> fixed upstream, which appears to have been missed (see patch 4 change log). The
> result is any distribution using the upstream 3.2 series kernel including and
> after v3.2.61 prevents other cores from being brought online if their platform's
> bootloader follows ePAPR (f.e. U-Boot) and only enables a single core during
> bootloader boot.
>
> Another alternative is to revert the patch listed above, I made the assumption
> boot problems were seen in this LTS kernel which caused the backporting of this
> patch in the first place, hence the 4 series patch set. Patch 4 actually fixes
> the problem but depends on patch 1 and 2 for functionality. The only patch
> that is not absolutly needed is patch 3 ("powerpc: Make logical to real cpu
> mapping"). Please let me know if a re-spin without patch 3 is wanted.
[...]
I've queued up all of these for 3.2 and will send them out for review
soon. Thanks a lot for digging these all out.
Ben.
--
Ben Hutchings
One of the nice things about standards is that there are so many of them.
Attachment:
signature.asc
Description: This is a digitally signed message part