Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Tue, 2010-02-09 at 11:46 +0100, Richard Cochran wrote:
> On Fri, Nov 06, 2009 at 10:32:00AM +0100, Philippe Gerum wrote:
> > On Fri, 2009-11-06 at 10:20 +0100, Richard Cochran wrote:
> > > Yes, works fine now. Thanks for your help.
>
> I am working again on PowerPC, and I now notice that I spoke too
> soon. I had fixed the problem for myself, in a different way.
>
Could you try a recent patch, say 2.6.32? This issue should have been
fixed there.
> The fix you gave is still not quite right.
>
> > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > index 8968b24..a4fe229 100644
> > --- a/arch/powerpc/kernel/smp.c
> > +++ b/arch/powerpc/kernel/smp.c
> > @@ -164,16 +164,16 @@ int smp_request_message_ipi(int virq, int msg)
> > if (msg < 0 || msg > PPC_MSG_DEBUGGER_BREAK) {
> > return -EINVAL;
> > }
>
> Even if this block...
>
> > -#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
> > - if (msg == PPC_MSG_DEBUGGER_BREAK) {
> > - return 1;
> > - }
> > -#endif
>
> > #ifdef CONFIG_IPIPE
> > if (msg == PPC_MSG_DEBUGGER_BREAK)
> > /* Piggyback the debugger IPI for the I-pipe. */
> > __ipipe_register_ipi(virq);
> > #endif
>
> appears here...
>
> > +#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
> > + if (msg == PPC_MSG_DEBUGGER_BREAK) {
> > + return 1;
> > + }
> > +#endif
>
> it still prevents the following call...
>
> > err = request_irq(virq, smp_ipi_action[msg], IRQF_DISABLED|IRQF_PERCPU,
> > smp_ipi_name[msg], 0);
>
> The function, smp_request_message_ipi(), is called unconditionally
> with virq=0,1,2,3, and 3=PPC_MSG_DEBUGGER_BREAK. AFAICT, ipipe needs
> the call to request_irq() to go through.
>
> I suggest:
>
> #ifdef CONFIG_IPIPE
> if (msg == PPC_MSG_DEBUGGER_BREAK)
> /* Piggyback the debugger IPI for the I-pipe. */
> __ipipe_register_ipi(virq);
> #else
> #if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
> if (msg == PPC_MSG_DEBUGGER_BREAK) {
> return 1;
> }
> #endif
> #endif
>
> Richard
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Fri, Nov 06, 2009 at 10:32:00AM +0100, Philippe Gerum wrote:
> On Fri, 2009-11-06 at 10:20 +0100, Richard Cochran wrote:
> > Yes, works fine now. Thanks for your help.
I am working again on PowerPC, and I now notice that I spoke too
soon. I had fixed the problem for myself, in a different way.
The fix you gave is still not quite right.
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 8968b24..a4fe229 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -164,16 +164,16 @@ int smp_request_message_ipi(int virq, int msg)
> if (msg < 0 || msg > PPC_MSG_DEBUGGER_BREAK) {
> return -EINVAL;
> }
Even if this block...
> -#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
> - if (msg == PPC_MSG_DEBUGGER_BREAK) {
> - return 1;
> - }
> -#endif
> #ifdef CONFIG_IPIPE
> if (msg == PPC_MSG_DEBUGGER_BREAK)
> /* Piggyback the debugger IPI for the I-pipe. */
> __ipipe_register_ipi(virq);
> #endif
appears here...
> +#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
> + if (msg == PPC_MSG_DEBUGGER_BREAK) {
> + return 1;
> + }
> +#endif
it still prevents the following call...
> err = request_irq(virq, smp_ipi_action[msg], IRQF_DISABLED|IRQF_PERCPU,
> smp_ipi_name[msg], 0);
The function, smp_request_message_ipi(), is called unconditionally
with virq=0,1,2,3, and 3=PPC_MSG_DEBUGGER_BREAK. AFAICT, ipipe needs
the call to request_irq() to go through.
I suggest:
#ifdef CONFIG_IPIPE
if (msg == PPC_MSG_DEBUGGER_BREAK)
/* Piggyback the debugger IPI for the I-pipe. */
__ipipe_register_ipi(virq);
#else
#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
if (msg == PPC_MSG_DEBUGGER_BREAK) {
return 1;
}
#endif
#endif
Richard
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Fri, 2009-11-06 at 10:20 +0100, Richard Cochran wrote:
> On Fri, Nov 06, 2009 at 09:26:58AM +0100, Philippe Gerum wrote:
> > Ouch. I just can't believe this went unnoticed for that long... Well, no
> > wonder why then, the critical IPI never gets registered, so never
> > detected by the pipeline core in __ipipe_grab_irq. Thanks for the heads
> > up.
> >
> > This may make things work a little better:
>
> Yes, works fine now. Thanks for your help.
Well, thank you for digging this issue, first.
>
> Richard
>
> > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > index 8968b24..a4fe229 100644
> > --- a/arch/powerpc/kernel/smp.c
> > +++ b/arch/powerpc/kernel/smp.c
> > @@ -164,16 +164,16 @@ int smp_request_message_ipi(int virq, int msg)
> > if (msg < 0 || msg > PPC_MSG_DEBUGGER_BREAK) {
> > return -EINVAL;
> > }
> > -#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
> > - if (msg == PPC_MSG_DEBUGGER_BREAK) {
> > - return 1;
> > - }
> > -#endif
> > #ifdef CONFIG_IPIPE
> > if (msg == PPC_MSG_DEBUGGER_BREAK)
> > /* Piggyback the debugger IPI for the I-pipe. */
> > __ipipe_register_ipi(virq);
> > #endif
> > +#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
> > + if (msg == PPC_MSG_DEBUGGER_BREAK) {
> > + return 1;
> > + }
> > +#endif
> >
> > err = request_irq(virq, smp_ipi_action[msg], IRQF_DISABLED|IRQF_PERCPU,
> > smp_ipi_name[msg], 0);
> >
> > --
> > Philippe.
> >
> >
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Fri, Nov 06, 2009 at 09:26:58AM +0100, Philippe Gerum wrote:
> Ouch. I just can't believe this went unnoticed for that long... Well, no
> wonder why then, the critical IPI never gets registered, so never
> detected by the pipeline core in __ipipe_grab_irq. Thanks for the heads
> up.
>
> This may make things work a little better:
Yes, works fine now. Thanks for your help.
Richard
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 8968b24..a4fe229 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -164,16 +164,16 @@ int smp_request_message_ipi(int virq, int msg)
> if (msg < 0 || msg > PPC_MSG_DEBUGGER_BREAK) {
> return -EINVAL;
> }
> -#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
> - if (msg == PPC_MSG_DEBUGGER_BREAK) {
> - return 1;
> - }
> -#endif
> #ifdef CONFIG_IPIPE
> if (msg == PPC_MSG_DEBUGGER_BREAK)
> /* Piggyback the debugger IPI for the I-pipe. */
> __ipipe_register_ipi(virq);
> #endif
> +#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
> + if (msg == PPC_MSG_DEBUGGER_BREAK) {
> + return 1;
> + }
> +#endif
>
> err = request_irq(virq, smp_ipi_action[msg], IRQF_DISABLED|IRQF_PERCPU,
> smp_ipi_name[msg], 0);
>
> --
> Philippe.
>
>
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Fri, 2009-11-06 at 09:10 +0100, Richard Cochran wrote:
> On Wed, Nov 04, 2009 at 11:16:21PM +0100, Philippe Gerum wrote:
> > 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.
>
> In file arch/powerpc/kernel/smp.c line 160, it appears that the IPIPE
> ifdef code is not reached when msg==3, which is the important value,
> AFAIKT.
>
> I have neither CONFIG_DEBUGGER nor CONFIG_KEXEC defined.
>
>
> int smp_request_message_ipi(int virq, int msg)
> {
> int err;
>
> if (msg < 0 || msg > PPC_MSG_DEBUGGER_BREAK) {
> return -EINVAL;
> }
> #if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
> if (msg == PPC_MSG_DEBUGGER_BREAK) {
> return 1;
> }
> #endif
> #ifdef CONFIG_IPIPE
> if (msg == PPC_MSG_DEBUGGER_BREAK)
> /* Piggyback the debugger IPI for the I-pipe. */
> __ipipe_register_ipi(virq);
> #endif
>
> err = request_irq(virq, smp_ipi_action[msg], IRQF_DISABLED|IRQF_PERCPU,
> smp_ipi_name[msg], 0);
> WARN(err < 0, "unable to request_irq %d for %s (rc %d)\n",
> virq, smp_ipi_name[msg], err);
>
> return err;
> }
Ouch. I just can't believe this went unnoticed for that long... Well, no
wonder why then, the critical IPI never gets registered, so never
detected by the pipeline core in __ipipe_grab_irq. Thanks for the heads
up.
This may make things work a little better:
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 8968b24..a4fe229 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -164,16 +164,16 @@ int smp_request_message_ipi(int virq, int msg)
if (msg < 0 || msg > PPC_MSG_DEBUGGER_BREAK) {
return -EINVAL;
}
-#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
- if (msg == PPC_MSG_DEBUGGER_BREAK) {
- return 1;
- }
-#endif
#ifdef CONFIG_IPIPE
if (msg == PPC_MSG_DEBUGGER_BREAK)
/* Piggyback the debugger IPI for the I-pipe. */
__ipipe_register_ipi(virq);
#endif
+#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
+ if (msg == PPC_MSG_DEBUGGER_BREAK) {
+ return 1;
+ }
+#endif
err = request_irq(virq, smp_ipi_action[msg], IRQF_DISABLED|IRQF_PERCPU,
smp_ipi_name[msg], 0);
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Wed, Nov 04, 2009 at 11:16:21PM +0100, Philippe Gerum wrote:
> 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.
In file arch/powerpc/kernel/smp.c line 160, it appears that the IPIPE
ifdef code is not reached when msg==3, which is the important value,
AFAIKT.
I have neither CONFIG_DEBUGGER nor CONFIG_KEXEC defined.
int smp_request_message_ipi(int virq, int msg)
{
int err;
if (msg < 0 || msg > PPC_MSG_DEBUGGER_BREAK) {
return -EINVAL;
}
#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
if (msg == PPC_MSG_DEBUGGER_BREAK) {
return 1;
}
#endif
#ifdef CONFIG_IPIPE
if (msg == PPC_MSG_DEBUGGER_BREAK)
/* Piggyback the debugger IPI for the I-pipe. */
__ipipe_register_ipi(virq);
#endif
err = request_irq(virq, smp_ipi_action[msg], IRQF_DISABLED|IRQF_PERCPU,
smp_ipi_name[msg], 0);
WARN(err < 0, "unable to request_irq %d for %s (rc %d)\n",
virq, smp_ipi_name[msg], err);
return err;
}
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
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 : lwz r0,-23316(r30) > 0xc000a5d8 : xor r0,r3,r0 > 0xc000a5dc : andi. r9,r0,3 > 0xc000a5e0 : 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. > Thanks, > Richard -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
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 : lwz r0,-23316(r30) 0xc000a5d8 : xor r0,r3,r0 0xc000a5dc : andi. r9,r0,3 0xc000a5e0 : 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? Thanks, Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
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. > > > I'll try and pull this apart some more... I was able to get SMP to boot, by accident. Using the BDI3000 telnet console, I halted the second core, and booted the SMP kernel on the first core. Then, I started the second core, which seems to work just fine! Weird. Wish me luck, Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Wed, 2009-11-04 at 12:15 +0100, Richard Cochran wrote: > On Wed, Nov 04, 2009 at 10:54:24AM +0100, Philippe Gerum wrote: > > > > The issue is more likely in the interrupt pipeline. When Xenomai is > > compiled as modules, does the system lock up when loading the nucleus, > > Yes. > > I looked at this problem using my shiny new BDI3000. > > mpcl8572>select 0 > Target CPU: MPC8572 Core#0 > Core state: halted > Debug entry cause : COP halt > Current PC: 0xc000aae4 > Current CR: 0x44044022 > Current MSR : 0x00021000 > Current LR: 0xc000aabc > Current CCSRBAR : 0x0_ffe0 > > mpc8572>select 1 > Target CPU: MPC8572 Core#1 > Core state: halted > Debug entry cause : COP halt > Current PC: 0xc006db38 > Current CR: 0x2222 > Current MSR : 0x00021000 > Current LR: 0xc006ed10 > Current CCSRBAR : 0x0_ffe0 > > System.map: > > c000a794 T __ipipe_send_ipi > c000a968 T ipipe_critical_enter > c000ab50 T __ipipe_enable_pipeline > > c006da60 T ipipe_release_tickdev > c006daf8 T __ipipe_check_percpu_access > c006dbf4 T __ipipe_set_irq_pending > > So, were stuck in ipipe_critical_enter() and __ipipe_check_percpu_access(). > Ok, this is a porting issue. The critical IPI (IPIPE_CRITICAL_IPI) does not seem to be properly handled on this platform. > I'll try and pull this apart some more... > > Richard > -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Wed, Nov 04, 2009 at 10:54:24AM +0100, Philippe Gerum wrote: > > The issue is more likely in the interrupt pipeline. When Xenomai is > compiled as modules, does the system lock up when loading the nucleus, Yes. I looked at this problem using my shiny new BDI3000. mpcl8572>select 0 Target CPU: MPC8572 Core#0 Core state: halted Debug entry cause : COP halt Current PC: 0xc000aae4 Current CR: 0x44044022 Current MSR : 0x00021000 Current LR: 0xc000aabc Current CCSRBAR : 0x0_ffe0 mpc8572>select 1 Target CPU: MPC8572 Core#1 Core state: halted Debug entry cause : COP halt Current PC: 0xc006db38 Current CR: 0x2222 Current MSR : 0x00021000 Current LR: 0xc006ed10 Current CCSRBAR : 0x0_ffe0 System.map: c000a794 T __ipipe_send_ipi c000a968 T ipipe_critical_enter c000ab50 T __ipipe_enable_pipeline c006da60 T ipipe_release_tickdev c006daf8 T __ipipe_check_percpu_access c006dbf4 T __ipipe_set_irq_pending So, were stuck in ipipe_critical_enter() and __ipipe_check_percpu_access(). I'll try and pull this apart some more... Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Wed, 2009-11-04 at 06:56 +0100, Richard Cochran wrote: > On Tue, Nov 03, 2009 at 03:44:24PM +0100, Philippe Gerum wrote: > > On Tue, 2009-11-03 at 14:34 +0100, Richard Cochran wrote: > > > If I enable ipipe only, I can still boot SMP. If Xenomai is enabled, > > > then the machine freezes as soon as Xenomai is started. (As a module, > > > Xenomai locks the machine when loading). > > > > Did you try enabling the pipeline debug options, like > > CONFIG_IPIPE_DEBUG_CONTEXT and CONFIG_IPIPE_DEBUG_INTERNAL? > > Yes, but it makes no difference, and I see no additional messages from > the kernel on the console. > > BTW, I also disabled CONFIG_XENO_OPT_PERVASIVE, but it still locks up. > The issue is more likely in the interrupt pipeline. When Xenomai is compiled as modules, does the system lock up when loading the nucleus, or do things go wrong when the first skin is loaded on top of this? > Richard -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Tue, Nov 03, 2009 at 03:44:24PM +0100, Philippe Gerum wrote: > On Tue, 2009-11-03 at 14:34 +0100, Richard Cochran wrote: > > If I enable ipipe only, I can still boot SMP. If Xenomai is enabled, > > then the machine freezes as soon as Xenomai is started. (As a module, > > Xenomai locks the machine when loading). > > Did you try enabling the pipeline debug options, like > CONFIG_IPIPE_DEBUG_CONTEXT and CONFIG_IPIPE_DEBUG_INTERNAL? Yes, but it makes no difference, and I see no additional messages from the kernel on the console. BTW, I also disabled CONFIG_XENO_OPT_PERVASIVE, but it still locks up. Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Tue, 2009-11-03 at 14:34 +0100, Richard Cochran wrote: > I have compiled and run ipipe-2.6.30.3-powerpc-2.7-02 and Xenomai > v2.4.9.1 (well, actually c4c3c82791951df998ac4dc463f79a76884577b6), on > two similar Freescale boards, the MPC8572DS and the P2020DS. Both are > dual core, and both run fine using vanilla Linux 2.6.30 with SMP. > > If I enable ipipe only, I can still boot SMP. If Xenomai is enabled, > then the machine freezes as soon as Xenomai is started. (As a module, > Xenomai locks the machine when loading). Did you try enabling the pipeline debug options, like CONFIG_IPIPE_DEBUG_CONTEXT and CONFIG_IPIPE_DEBUG_INTERNAL? > > Without SMP, it seems to run fine (and latency numbers are excellent!) > > I seem to recall having seen that Xenomai SMP was working on some > other Freescale powerpc chips. Looking for any advice... Xenomai runs on Emerson's mvme7100 powered by a 8641D, but FSL eval boards which are known to work with Xenomai are uniprocessor only so far. SMP-wise, PA-Semi's PA6T (ppc64) and Emerson's mvme7100 (ppc32) are known to work, but I can't tell for any other hw. > > Thanks, > > Richard > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
