On Sep 23, 2011, at 11:32 AM, Scott Wood wrote: > On 09/23/2011 10:01 AM, Jimi Xenidis wrote: >> From: David Gibson <d...@au1.ibm.com> >> >> Based on patch by David Gibson <d...@au1.ibm.com> >> >> xmon has a longstanding bug on systems which are SMP-capable but lack >> the MSR[RI] bit. In these cases, xmon invoked by IPI on secondary >> CPUs will not properly keep quiet, but will print stuff, thereby >> garbling the primary xmon's output. This patch fixes it, by ignoring >> the RI bit if the processor does not support it. >> >> There's already a version of this for 4xx upstream, which we'll need >> to extend to other RI-lacking CPUs at some point. For now this adds >> Book3e processors to the mix. >> >> Signed-off-by: Jimi Xenidis <ji...@pobox.com> >> >> --- >> Restricted it to Book3e >> --- >> arch/powerpc/xmon/xmon.c | 4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c >> index 42541bb..13f82f8 100644 >> --- a/arch/powerpc/xmon/xmon.c >> +++ b/arch/powerpc/xmon/xmon.c >> @@ -340,8 +340,8 @@ int cpus_are_in_xmon(void) >> >> static inline int unrecoverable_excp(struct pt_regs *regs) >> { >> -#ifdef CONFIG_4xx >> - /* We have no MSR_RI bit on 4xx, so we simply return false */ >> +#if defined(CONFIG_4xx) || defined(CONFIG_BOOK3E) >> + /* We have no MSR_RI bit on 4xx or Book3e, so we simply return false */ >> return 0; >> #else >> return ((regs->msr & MSR_RI) == 0); > > How is CONFIG_BOOK3E better than CONFIG_BOOKE? Both e500mc (has RI) and > e500v2 (doesn't have RI) will select both symbols. Sounds like it > should be a cputable flag.
Ben was not in favor of wasting a cpu feature bit on this. I figured that since Book3e ISA does not support an RI bit than I would leave that too the those who extend it. :) Any other ideas are welcome. -JX > > -Scott > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev