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.
Is there some /proc or /sys file I can read to tell you?
Though if it's something that changes dynamically, then what
I read now might not be what it would say when things go wrong.
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.