2011-05-17 16:28:36

by Richard Cochran

[permalink] [raw]
Subject: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

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 <[email protected]>
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.


2011-05-17 21:40:34

by Benjamin Herrenschmidt

[permalink] [raw]
Subject: Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

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 <[email protected]>
> 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.

2011-05-18 12:03:28

by Richard Cochran

[permalink] [raw]
Subject: Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

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 <[email protected]>
> > 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

2011-05-18 21:48:30

by Benjamin Herrenschmidt

[permalink] [raw]
Subject: Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame

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.

2011-05-18 21:49:11

by Benjamin Herrenschmidt

[permalink] [raw]
Subject: Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame


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

2011-05-19 05:33:04

by Kumar Gala

[permalink] [raw]
Subject: Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame


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

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

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

- k-

2011-05-19 05:33:24

by Kumar Gala

[permalink] [raw]
Subject: Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame


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 <[email protected]>
>> 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