Subject: Re: next-20120313 cpuidle freezes when booting

From: Daniel Lezcano <[email-masked]>
Date: Wed, 14 Mar 2012 20:46:57 +0100

On 03/14/2012 08:03 PM, Hugh Dickins wrote:
> On Wed, 14 Mar 2012, Daniel Lezcano wrote:
>> On 03/13/2012 11:29 PM, Hugh Dickins wrote:
>>> Hi Stephen,
>>>
>>> Yesterday's 3.3.0-rc7-next-20120313 gives me unpredictable freezes
>>> on x86_64, on a ThinkPad T420s - I've not dared it on more machines.
>>>
>>> Usually when booting up (sometimes just after Freeing unused kernel
>>> memory, sometimes random places elsewhere), but occasionally it manages
>>> to get as far as X; doesn't usually manage to complete suspend+resume.
>>>
>>> 3.3.0-rc6-nex-20120309 behaved similarly; the last I tried before
>>> that was 3.3.0-rc5-next20120227, which was okay.
>>>
>>> Bisection led me to "cpuidle: Add common time keeping and irq enabling",
>>> (from the cpuidle-cons tree I think), and reverting that has so far
>>> given me a working system (it's a success if I complete this mail).
>>>
>>> Below is the patch I've used to revert it (for other people having
>>> problems with recent linux-next to try); but it's not quite correct,
>>> because you did a merge on conflicting trees there, and I didn't spend
>>> time to unravel all that, just get a working x86 system - since I've
>>> left out some of your merge (in arch/arm/kernel/Makefile and arch/arm/
>>> mach-at91/cpuidle.c), this reversion probably breaks arm as is.
>>
>> Hi Hugh,
>>
>> is it possible you give the cpuidle driver your host is using ?
>
> "grep IDLE .config" tells me:
>
> CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
> CONFIG_ARCH_HAS_DEFAULT_IDLE=y
> CONFIG_CPU_IDLE=y
> CONFIG_CPU_IDLE_GOV_LADDER=y
> CONFIG_CPU_IDLE_GOV_MENU=y
> CONFIG_INTEL_IDLE=y
> # CONFIG_I7300_IDLE is not set
>
> but I've a feeling that isn't what you need to know.

Thanks for these informations, I forgot to ask you for them.
By the way, do you have CONFIG_ARCH_HAS_CPU_RELAX  ?

> Is there some /proc or /sys file I can read to tell you?

Yes, the content of /sys/devices/system/cpu/cpuidle/current_driver
and /sys/devices/system/cpu/cpuidle/current_governor_ro

> Though if it's something that changes dynamically, then what
> I read now might not be what it would say when things go wrong.

No, that won't change, so the information should be enough for me to 
find the code path where the regression is.

> I expect you've realized by now, I haven't a clue about cpuidle
> drivers: I hadn't even realized that idleness needs a driver.

No problem, thanks for git bisecting and find the culprit :)

   -- Daniel

-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog