[Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Richard Cochran]

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).

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...

Thanks,

Richard

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Philippe Gerum]

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@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 
Philippe.

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Richard Cochran]

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

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Philippe Gerum]

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.

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Richard Cochran]

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_ffe00000

mpc8572>select 1
    Target CPU        : MPC8572 Core#1
    Core state        : halted
    Debug entry cause : COP halt
    Current PC        : 0xc006db38
    Current CR        : 0x22000022
    Current MSR       : 0x00021000
    Current LR        : 0xc006ed10
    Current CCSRBAR   : 0x0_ffe00000

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

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Philippe Gerum]

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_ffe00000
> 
> mpc8572>select 1
>     Target CPU        : MPC8572 Core#1
>     Core state        : halted
>     Debug entry cause : COP halt
>     Current PC        : 0xc006db38
>     Current CR        : 0x22000022
>     Current MSR       : 0x00021000
>     Current LR        : 0xc006ed10
>     Current CCSRBAR   : 0x0_ffe00000
> 
> 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.

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Richard Cochran]

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

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Richard Cochran]

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?

Thanks,
Richard

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Philippe Gerum]

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.

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Richard Cochran]

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;
}

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Philippe Gerum]

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.

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Richard Cochran]

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.
> 
> 

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Philippe Gerum]

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.

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Richard Cochran]

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

Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP

[Philippe Gerum]

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.