powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

[Richard Cochran]

Ben,

Recent 2.6.39-rc kernels behave strangely on the Freescale dual core
mpc8572 and p2020. There is a long pause (like 2 seconds) in the boot
sequence after "mpic: requesting IPIs..."

When the system comes up, only one core shows in /proc/cpuinfo. Later
on, lots of messages appear like the following:

   INFO: task ksoftirqd/1:9 blocked for more than 120 seconds.

I bisected [1] the problem to:

   commit c56e58537d504706954a06570b4034c04e5b7500
   Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
   Date:   Tue Mar 8 14:40:04 2011 +1100

       powerpc/smp: Create idle threads on demand and properly reset them

I don't see from that commit what had gone wrong. Perhaps you can
help resolve this?

Thanks,
Richard


1. I had to patch commit e5462d16 by hand when bisecting, which is a
   fixup for commit fa3f82c8 and not yet merged in c56e5853.

Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

[Benjamin Herrenschmidt]

On Tue, 2011-05-17 at 18:28 +0200, Richard Cochran wrote:
> Ben,
> 
> Recent 2.6.39-rc kernels behave strangely on the Freescale dual core
> mpc8572 and p2020. There is a long pause (like 2 seconds) in the boot
> sequence after "mpic: requesting IPIs..."
> 
> When the system comes up, only one core shows in /proc/cpuinfo. Later
> on, lots of messages appear like the following:
> 
>    INFO: task ksoftirqd/1:9 blocked for more than 120 seconds.
> 
> I bisected [1] the problem to:
> 
>    commit c56e58537d504706954a06570b4034c04e5b7500
>    Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>    Date:   Tue Mar 8 14:40:04 2011 +1100
> 
>        powerpc/smp: Create idle threads on demand and properly reset them
> 
> I don't see from that commit what had gone wrong. Perhaps you can
> help resolve this?

Hrm, odd. Kumar, care to have a look ? That's what happens when you
don't get me HW to test with :-)

Cheers,
Ben.

> Thanks,
> Richard
> 
> 
> 1. I had to patch commit e5462d16 by hand when bisecting, which is a
>    fixup for commit fa3f82c8 and not yet merged in c56e5853.

Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

[Richard Cochran]

On Wed, May 18, 2011 at 07:40:16AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2011-05-17 at 18:28 +0200, Richard Cochran wrote:
> > Ben,
> > 
> > Recent 2.6.39-rc kernels behave strangely on the Freescale dual core
> > mpc8572 and p2020. There is a long pause (like 2 seconds) in the boot
> > sequence after "mpic: requesting IPIs..."
> > 
> > When the system comes up, only one core shows in /proc/cpuinfo. Later
> > on, lots of messages appear like the following:
> > 
> >    INFO: task ksoftirqd/1:9 blocked for more than 120 seconds.
> > 
> > I bisected [1] the problem to:
> > 
> >    commit c56e58537d504706954a06570b4034c04e5b7500
> >    Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >    Date:   Tue Mar 8 14:40:04 2011 +1100
> > 
> >        powerpc/smp: Create idle threads on demand and properly reset them
> > 
> > I don't see from that commit what had gone wrong. Perhaps you can
> > help resolve this?
> 
> Hrm, odd. Kumar, care to have a look ? That's what happens when you
> don't get me HW to test with :-)

(I get the feeling that I am the only one testing recent kernels with
the mpc85xx.)

Anyhow, I see that this commit was one of a series. For my own use,
can I simply revert this one commit independently?

Thanks,
Richard

Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

[Milton Miller]

Does this patch help?  If so please reply to that thread so patchwork
will see it in addition to here.

http://patchwork.ozlabs.org/patch/96146/

milton

Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

[Benjamin Herrenschmidt]

On Wed, 2011-05-18 at 12:19 -0500, Milton Miller wrote:
> Does this patch help?  If so please reply to that thread so patchwork
> will see it in addition to here.
> 
> http://patchwork.ozlabs.org/patch/96146/

Interesting. I'll have a closer look today. Unfortunately, I don't have
any 32-bit BookE SMP at hand at the moment so I couldn't test those
configs.

Cheers,
Ben.

Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

[Benjamin Herrenschmidt]

> (I get the feeling that I am the only one testing recent kernels with
> the mpc85xx.)
> 
> Anyhow, I see that this commit was one of a series. For my own use,
> can I simply revert this one commit independently?

For your own use sure :-) But I'd still like to get to the bottom of
this !

Cheers,
Ben.

Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

[Kumar Gala]

On May 18, 2011, at 4:48 PM, Benjamin Herrenschmidt wrote:

>=20
>> (I get the feeling that I am the only one testing recent kernels with
>> the mpc85xx.)
>>=20
>> Anyhow, I see that this commit was one of a series. For my own use,
>> can I simply revert this one commit independently?
>=20
> For your own use sure :-) But I'd still like to get to the bottom of
> this !
>=20
> Cheers,
> Ben.

Tested the 'merge' branch and it appears to fix the issues with =
secondary cores coming up.

- k=

Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

[Kumar Gala]

On May 17, 2011, at 4:40 PM, Benjamin Herrenschmidt wrote:

> On Tue, 2011-05-17 at 18:28 +0200, Richard Cochran wrote:
>> Ben,
>> 
>> Recent 2.6.39-rc kernels behave strangely on the Freescale dual core
>> mpc8572 and p2020. There is a long pause (like 2 seconds) in the boot
>> sequence after "mpic: requesting IPIs..."
>> 
>> When the system comes up, only one core shows in /proc/cpuinfo. Later
>> on, lots of messages appear like the following:
>> 
>>   INFO: task ksoftirqd/1:9 blocked for more than 120 seconds.
>> 
>> I bisected [1] the problem to:
>> 
>>   commit c56e58537d504706954a06570b4034c04e5b7500
>>   Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>   Date:   Tue Mar 8 14:40:04 2011 +1100
>> 
>>       powerpc/smp: Create idle threads on demand and properly reset them
>> 
>> I don't see from that commit what had gone wrong. Perhaps you can
>> help resolve this?
> 
> Hrm, odd. Kumar, care to have a look ? That's what happens when you
> don't get me HW to test with :-)

I'm trying to work on it ;)

- k