From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Lezcano Subject: Re: next-20120313 cpuidle freezes when booting Date: Wed, 14 Mar 2012 20:46:57 +0100 Message-ID: <4F60F5B1.8070302@linaro.org> References: <4F608116.80508@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-ee0-f46.google.com ([74.125.83.46]:51302 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030443Ab2CNTrB (ORCPT ); Wed, 14 Mar 2012 15:47:01 -0400 Received: by eekc41 with SMTP id c41so1266664eek.19 for ; Wed, 14 Mar 2012 12:46:59 -0700 (PDT) In-Reply-To: Sender: linux-next-owner@vger.kernel.org List-ID: To: Hugh Dickins Cc: Stephen Rothwell , Andrew Morton , Robert Lee , Jean Pihet , Kevin Hilman , Deepthi Dharwar , Dan Carpenter , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org 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= =2E >>> >>> Usually when booting up (sometimes just after Freeing unused kernel >>> memory, sometimes random places elsewhere), but occasionally it man= ages >>> to get as far as X; doesn't usually manage to complete suspend+resu= me. >>> >>> 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 enabl= ing", >>> (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 sp= end >>> time to unravel all that, just get a working x86 system - since I'v= e >>> left out some of your merge (in arch/arm/kernel/Makefile and arch/a= rm/ >>> 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=3Dy > CONFIG_ARCH_HAS_DEFAULT_IDLE=3Dy > CONFIG_CPU_IDLE=3Dy > CONFIG_CPU_IDLE_GOV_LADDER=3Dy > CONFIG_CPU_IDLE_GOV_MENU=3Dy > CONFIG_INTEL_IDLE=3Dy > # 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=20 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 --=20 Linaro.org =E2=94=82 Open source software fo= r ARM SoCs =46ollow Linaro: Facebook | Twitter | Blog