[PATCH] ppc32: handle Book E debug exceptions on kernel stack

[Dale Farnsworth]

On Tue, Feb 14, 2006 at 03:57:58PM -0600, Kumar Gala wrote:
> Let me look at this a little, however, I'm amused by the 

Thanks.

> smp_processor_id() usage on 8548.  Its a single core SoC, so any reason 
> SMP is turned on in your kernel?

I haven't turned on SMP in my 8548 kernel.

The kgdb singlestep code calls smp_processor_id() even on UP.
It doesn't really need to call it on UP, but smp_processor_id()
still should work.  I would have preferred seeing #ifdef
CONFIG_SMP scattered throughout that code, but it's not my code.
Anyway, the smp_processor_id() calls happen to return the
correct value on UP, even on the critical exception stack,
since that stack area is initialized to 0.

The issue I actually hit is that for CONFIG_PREEMPT, the calls
to spin_lock() and spin_unlock() increment and decrement
current_thread_info()->preempt_count. This breaks things
when the preempt_count goes negative.

> Not, that your patch, isn't needed for a SMP Book-E, just wondering.

Yes, I'm looking forward to trying out a dual-core processor.

-Dale

> On Tue, 14 Feb 2006, Dale Farnsworth wrote:
> 
> > From: Dale Farnsworth <dale at farnsworth.org>
> > 
> > On PPC Book E processsors, we currently handle debug
> > exceptions on the critical exception stack (debug stack
> > for E200).  This causes problems with the kgdb single
> > step handler, which calls smp_processor_id() and spin_lock(),
> > which reference current_thread_info(), which only works when
> > we are on the kernel stack.
> > 
> > We address this by switching to the kernel stack early while
> > handling debug exceptions.  Note that the entry values of r10
> > and r11 are still saved on the critical exception (or debug) stack.
> > 
> > Signed-off-by: Dale Farnsworth <dale at farnsworth.org>