On Wed, 2009-11-04 at 19:19 +0100, Richard Cochran wrote:
> On Wed, Nov 04, 2009 at 03:08:32PM +0100, Richard Cochran wrote:
> > On Wed, Nov 04, 2009 at 12:26:45PM +0100, Philippe Gerum wrote:
> > > Ok, this is a porting issue. The critical IPI (IPIPE_CRITICAL_IPI) does
> > > not seem to be properly handled on this platform.
> Okay, after playing with the BDI3000 today, I have found out that both
> cores end up running in infinite loops.
> Core 0 runs this loop in ipipe_critical_enter() at
> while (!cpus_equal(__ipipe_cpu_sync_map, lock_map))
> Dissambles to...
> 0xc000a5d4 <ipipe_critical_enter+368>: lwz r0,-23316(r30)
> 0xc000a5d8 <ipipe_critical_enter+372>: xor r0,r3,r0
> 0xc000a5dc <ipipe_critical_enter+376>: andi. r9,r0,3
> 0xc000a5e0 <ipipe_critical_enter+380>: bne+ 0xc000a5d4
> Core 1 runs an infinite loop in cpu_idle() calling into
> ipipe_suspend_domain() now and again. The stack looks like:
> #0 ipipe_suspend_domain () at kernel/ipipe/core.c:614
> #1 0xc0008c0c in cpu_idle () at arch/powerpc/kernel/idle.c:62
> #2 0xc030262c in start_secondary () at arch/powerpc/kernel/smp.c:556
> #3 0xc0001ca8 in __secondary_start ()
> I realize this is only the symptom, but now I'll study the code
> leading up to this condition.
> Any ideas on the prossible cause, Philippe?
Core 0 waits for core 1 to acknowledge the critical IPI, but that
lazybones prefers to sleep. Likely because it did not receive the IPI in
question, actually (it should raise a bit in __ipipe_cpu_sync_map, see
__ipipe_do_critical_sync). You may want to find the reason why the IPI
sent in ipipe_critical_enter() does not propagate to the other core.
Xenomai-core mailing list