diff mbox

ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

Message ID 20140523183228.GH2321@atomide.com (mailing list archive)
State New, archived
Headers show

Commit Message

Tony Lindgren May 23, 2014, 6:32 p.m. UTC
* Tony Lindgren <tony@atomide.com> [140523 07:45]:
> * Tobias Jakobi <tjakobi@math.uni-bielefeld.de> [140519 14:19]:
> > 
> > But even if I don't connect via WiFi at all, just boot and let me system
> > run with serial console connected, after some time I get a kernel 'WARNING':
> > http://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg.1.log
> 
> BTW, care to update the bugzilla page with the second warning
> in this log?
> 
> That's the WARNING: CPU: 1 PID: 0 at kernel/timer.c:1147 that's
> at 238 seconds.

Also, with Santosh's fix applied, can you also try disabling one
or more of the idle states for cpuidle and see if that helps?

Something like this patch below. If that helps with the WARNING
above you're getting it narrows down the problem down quite a bit.

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Tony Lindgren May 27, 2014, 8:34 p.m. UTC | #1
* Daniel Lezcano <daniel.lezcano@linaro.org> [140523 13:53]:
> On 23 May 2014 20:32, Tony Lindgren <tony@atomide.com> wrote:
> 
> > * Tony Lindgren <tony@atomide.com> [140523 07:45]:
> > > * Tobias Jakobi <tjakobi@math.uni-bielefeld.de> [140519 14:19]:
> > > >
> > > > But even if I don't connect via WiFi at all, just boot and let me
> > system
> > > > run with serial console connected, after some time I get a kernel
> > 'WARNING':
> > > > http://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg.1.log
> > >
> > > BTW, care to update the bugzilla page with the second warning
> > > in this log?
> > >
> > > That's the WARNING: CPU: 1 PID: 0 at kernel/timer.c:1147 that's
> > > at 238 seconds.
> >
> > Also, with Santosh's fix applied, can you also try disabling one
> > or more of the idle states for cpuidle and see if that helps?
> >
> > Something like this patch below. If that helps with the WARNING
> > above you're getting it narrows down the problem down quite a bit.
> >
> > Regards,
> >
> > Tony
> >
> > --- a/arch/arm/mach-omap2/cpuidle44xx.c
> > +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> > @@ -44,11 +44,13 @@ static struct idle_statedata omap4_idle_data[] = {
> >                 .mpu_state = PWRDM_POWER_RET,
> >                 .mpu_logic_state = PWRDM_POWER_RET,
> >         },
> > +#if 0
> >         {
> >                 .cpu_state = PWRDM_POWER_OFF,
> >                 .mpu_state = PWRDM_POWER_RET,
> >                 .mpu_logic_state = PWRDM_POWER_OFF,
> >         },
> > +#endif
> >
> 
> Hmm, I am afraid that will lead to a fault. Safer to set the state_count =
> 2 instead.

Hmm don't we have state_count = ARRAY_SIZE(omap4_idle_data) or am I
missing something?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Santosh Shilimkar May 27, 2014, 9:03 p.m. UTC | #2
On Tuesday 27 May 2014 04:34 PM, Tony Lindgren wrote:
> * Daniel Lezcano <daniel.lezcano@linaro.org> [140523 13:53]:
>> On 23 May 2014 20:32, Tony Lindgren <tony@atomide.com> wrote:
>>
>>> * Tony Lindgren <tony@atomide.com> [140523 07:45]:
>>>> * Tobias Jakobi <tjakobi@math.uni-bielefeld.de> [140519 14:19]:
>>>>>
>>>>> But even if I don't connect via WiFi at all, just boot and let me
>>> system
>>>>> run with serial console connected, after some time I get a kernel
>>> 'WARNING':
>>>>> http://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg.1.log
>>>>
>>>> BTW, care to update the bugzilla page with the second warning
>>>> in this log?
>>>>
>>>> That's the WARNING: CPU: 1 PID: 0 at kernel/timer.c:1147 that's
>>>> at 238 seconds.
>>>
>>> Also, with Santosh's fix applied, can you also try disabling one
>>> or more of the idle states for cpuidle and see if that helps?
>>>
>>> Something like this patch below. If that helps with the WARNING
>>> above you're getting it narrows down the problem down quite a bit.
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>> --- a/arch/arm/mach-omap2/cpuidle44xx.c
>>> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
>>> @@ -44,11 +44,13 @@ static struct idle_statedata omap4_idle_data[] = {
>>>                 .mpu_state = PWRDM_POWER_RET,
>>>                 .mpu_logic_state = PWRDM_POWER_RET,
>>>         },
>>> +#if 0
>>>         {
>>>                 .cpu_state = PWRDM_POWER_OFF,
>>>                 .mpu_state = PWRDM_POWER_RET,
>>>                 .mpu_logic_state = PWRDM_POWER_OFF,
>>>         },
>>> +#endif
>>>
>>
>> Hmm, I am afraid that will lead to a fault. Safer to set the state_count =
>> 2 instead.
> 
> Hmm don't we have state_count = ARRAY_SIZE(omap4_idle_data) or am I
> missing something?
> 
I don't think you are missing anything. The change should work.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Daniel Lezcano May 27, 2014, 9:06 p.m. UTC | #3
On 05/27/2014 11:03 PM, Santosh Shilimkar wrote:
> On Tuesday 27 May 2014 04:34 PM, Tony Lindgren wrote:
>> * Daniel Lezcano <daniel.lezcano@linaro.org> [140523 13:53]:
>>> On 23 May 2014 20:32, Tony Lindgren <tony@atomide.com> wrote:
>>>
>>>> * Tony Lindgren <tony@atomide.com> [140523 07:45]:
>>>>> * Tobias Jakobi <tjakobi@math.uni-bielefeld.de> [140519 14:19]:
>>>>>>
>>>>>> But even if I don't connect via WiFi at all, just boot and let me
>>>> system
>>>>>> run with serial console connected, after some time I get a kernel
>>>> 'WARNING':
>>>>>> http://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg.1.log
>>>>>
>>>>> BTW, care to update the bugzilla page with the second warning
>>>>> in this log?
>>>>>
>>>>> That's the WARNING: CPU: 1 PID: 0 at kernel/timer.c:1147 that's
>>>>> at 238 seconds.
>>>>
>>>> Also, with Santosh's fix applied, can you also try disabling one
>>>> or more of the idle states for cpuidle and see if that helps?
>>>>
>>>> Something like this patch below. If that helps with the WARNING
>>>> above you're getting it narrows down the problem down quite a bit.
>>>>
>>>> Regards,
>>>>
>>>> Tony
>>>>
>>>> --- a/arch/arm/mach-omap2/cpuidle44xx.c
>>>> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
>>>> @@ -44,11 +44,13 @@ static struct idle_statedata omap4_idle_data[] = {
>>>>                  .mpu_state = PWRDM_POWER_RET,
>>>>                  .mpu_logic_state = PWRDM_POWER_RET,
>>>>          },
>>>> +#if 0
>>>>          {
>>>>                  .cpu_state = PWRDM_POWER_OFF,
>>>>                  .mpu_state = PWRDM_POWER_RET,
>>>>                  .mpu_logic_state = PWRDM_POWER_OFF,
>>>>          },
>>>> +#endif
>>>>
>>>
>>> Hmm, I am afraid that will lead to a fault. Safer to set the state_count =
>>> 2 instead.
>>
>> Hmm don't we have state_count = ARRAY_SIZE(omap4_idle_data) or am I
>> missing something?
>>
> I don't think you are missing anything. The change should work.

Oh, yes. Sorry, over-sighted that. I am too used with the other drivers 
assigning the state_count with a number.
diff mbox

Patch

--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -44,11 +44,13 @@  static struct idle_statedata omap4_idle_data[] = {
 		.mpu_state = PWRDM_POWER_RET,
 		.mpu_logic_state = PWRDM_POWER_RET,
 	},
+#if 0
 	{
 		.cpu_state = PWRDM_POWER_OFF,
 		.mpu_state = PWRDM_POWER_RET,
 		.mpu_logic_state = PWRDM_POWER_OFF,
 	},
+#endif
 };
 
 static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];