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.
Anton Blanchard (1):
powerpc: Make logical to real cpu mapping code endian safe
Grant Likely (1):
of: Add of_property_match_string() to find index into a string list
Scott Wood (1):
powerpc: Don't skip ePAPR spin-table CPUs
Thierry Reding (1):
dt: Add empty of_property_match_string() function
arch/powerpc/kernel/setup-common.c | 16 ++++++++++++----
drivers/of/base.c | 36 ++++++++++++++++++++++++++++++++++++
include/linux/of.h | 10 ++++++++++
3 files changed, 58 insertions(+), 4 deletions(-)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html