On Fri, Jul 31, 2009 at 08:37:22AM +0930, Rusty Russell wrote: > On Fri, 31 Jul 2009 02:16:29 am Dave Jones wrote: > > On Thu, Jul 30, 2009 at 11:38:22AM -0500, Langsdorf, Mark wrote: > > > I'll look into it. > > > > > > First time I've had this bug reported, though. > > > > > > > It's happening because the suspend code runs with interrupts disabled, > > and the powerpc workaround we do in the cpufreq suspend hook > > calls the drivers ->get method. > > > > powernow-k8's ->get does an smp_call_function_single > > which needs interrupts enabled > > Yeah, I was confused: my patch changed set_cpus_allowed_ptr() to > an smp_call_function. If the latter is a bad idea with irqs disabled, the > former certainly was... Right, the only reason reverting your change 'fixes' the problem is that we don't have a BUG() in set_cpus_allowed_ptr to check for interrupts being disabled. hmm, does adding an equivalent check make sense? cpufreq seemed to cope just fine when we used set_cpus_allowed_ptr, but we might have just got lucky. As we were suspending in this path, interaction from the scheduler is minimal. Other callers might not be so lucky? Dave -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
