Kevin,
On 05/09/2014 01:15 AM, Kevin Hilman wrote:
> Tony Lindgren <tony@xxxxxxxxxxx> writes:
>
> [...]
>
>> ..but I think I found the cause for recent hangs on panda, just a wild
>> guess based on looking at the recent cpuidle patches after v3.14.
>>
>> Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts
>> until all coupled CPUs leave idle) makes booting work reliably again
>> on panda.
>>
>> Can you guys confirm, so far no issues here after few boot tests,
>> but it might be too early to tell.
>
> Reverting that makes things a bit more stable, but it still eventually
> fails in the same way. For me it took 8 boots for it to eventually
> fail.
>
> However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable
> (20+ boots in a row and still going.)
>
Can you please test with CPU_IDLE enabled but C3 disabled as in below patch?
It worked for me 10/10 boots.
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..99362ff 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -206,7 +206,12 @@ static struct cpuidle_driver omap4_idle_driver = {
.desc = "CPUx OFF, MPUSS OSWR",
},
},
- .state_count = ARRAY_SIZE(omap4_idle_data),
+/*
+ * Disable C3 state since it is unstable
+ *
+ * .state_count = ARRAY_SIZE(omap4_idle_data),
+ */
+ .state_count = 2,
.safe_state_index = 0,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
