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>
