Hi Daniel,

Daniel Lezcano [off-list ref] hat am 5. November 2016 um 14:00
geschrieben:


On Sat, Nov 05, 2016 at 01:01:26PM +0100, Stefan Wahren wrote:

[?... ]

quoted

quoted

quoted

CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM=y
CONFIG_CPU_IDLE is not set

hmmm, why not have CONFIG_CPU_IDLE set?

I'm using mxs_defconfig which doesn't select the ARM CPU idle. Is this
necessary?

Very likely :) suspend_freezer and cpuidle are tied together.

Moreover, while reading the code, it appears without CONFIG_CPU_IDLE the
function cpuidle_idle_call is constantly failing, ending up by having the
cpu looping again and again in the idle loop. The function stubs return
-ENODEV in the cpuidle's header when CONFIG_CPU_IDLE is not set.

If I'm not wrong the traces should show the cpu actually does never go
to suspend. As soon as it enters the state, it should exit immediately
without an interrupt event.

Probably there is an inconsistent configuration leaving the kernel with
a strange wakeup condition or a race with the short the suspend/resume
cycle delay.

First test would be to enable CONFIG_CPU_IDLE.

If it is confirmed, it would be nice to feed bugzilla.

first i tried with CONFIG_CPU_IDLE=Y and then additionally with
CONFIG_ARM_CPUIDLE=y.

In both cases the issue is still reproducible.

As i wrote in my email before, i added a pr_info() into freeze_wake. But i never
see the output of this message. So i assume freeze_wake is never called. Again,
how could this happen?