| Message ID | 536C9084.50209@ti.com |
|---|---|
| State | New |
| Headers | show |
Roger Quadros <rogerq@ti.com> writes: > Kevin, > > On 05/09/2014 01:15 AM, Kevin Hilman wrote: >> Tony Lindgren <tony@atomide.com> 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. Yup, it worked for me too for 10/10 boots in a row. Kevin -- 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
* Kevin Hilman <khilman@linaro.org> [140509 16:46]: > Roger Quadros <rogerq@ti.com> writes: > > > Kevin, > > > > On 05/09/2014 01:15 AM, Kevin Hilman wrote: > >> Tony Lindgren <tony@atomide.com> 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. > > Yup, it worked for me too for 10/10 boots in a row. But what has caused this regression, does it work reliably with let's say v3.13 or v3.12? 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
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, };