On 28/04/15 11:34, Daniel Lezcano wrote:
On 04/28/2015 12:11 PM, Linus Walleij wrote:
On Thu, Apr 2, 2015 at 12:22 AM, Rafael J. Wysocki
<rjw@xxxxxxxxxxxxx> wrote:
From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Replace the clockevents_notify() call with an explicit function
call.
Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
For some reason this makes my Ux500 system arbitrarily hang,
especially during boot. Bisected down to this commit. Since the
entire changeset is removing the notifications altogether I can't
just revert it.
Disabling CONFIG_CPU_IDLE removes the problem.
Tried registering a stub driver (I just #if 0 all the code in
drivers/cpuidle/cpuidle-ux500.c) it still crashes.
That makes me think something inside the cpuidle subsystem is
locking up after this, but my other idea is that the timer may be
involved in some way, like this is stressing the timer in some new
yet untested way.
Has anyone else seen problems with this or is it only ux500?
I'm looking closer at it but feel a bit clueless...
If you keep the #if 0 and remove the CPUIDLE_FLAG_TIMER_STOP flag,
does it still crash ?
At-least I observed issue only when I am using hardware broadcast timer.
It doesn't hang when I am using hrtimer as broadcast timer in which case
one of the cpu will be not enter deeper idle states that lose timer.
I will rerun on v4.1-rc1 and post the complete log.
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
