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 > arch/powerpc/kernel/ipipe.c:278 > > while (!cpus_equal(__ipipe_cpu_sync_map, lock_map)) > cpu_relax(); > > 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 > <ipipe_critical_enter+368> > > 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. > Thanks, > Richard -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
