On Tuesday, April 28, 2015 03:31:54 PM Rafael J. Wysocki wrote: > On Tuesday, April 28, 2015 02:37:10 PM Linus Walleij wrote: > > On Tue, Apr 28, 2015 at 2:19 PM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > Sudeep: > > >> 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. > > > > > > So the bug here is that cpuidle_enter() enables interrupts, so the > > > assumption about them being not enabled made by > > > tick_broadcast_oneshot_control() is actually not valid. > > > > > > It looks like we need to acquire the clockevents_lock at least in this > > > particular case. Let me see where to put it and I'll send a patch for > > > testing. > > > > Aha that looks very much like it. Put me on the patch and I'll > > take it for a spin. > > OK, so something like the below for starters (the _irqsave variant is used to > avoid adding one more WARN_ON(irqs_disabled()) in there). > > I haven't tested it, but then I can't reproduce the original issue in the > first place. Of course, the whole "broadcast" thing could be done from cpuidle_enter() in the first place, but then we could not avoid the problem with the cpuidle *callback* enabling interrupts possibly in there anyway (not to mention the "coupled" stuff). -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
