On 09-07-15, 02:13, Rafael J. Wysocki wrote: > So the cpufreq driver's ->get() callback returns 0 for the given CPU and > that's what triggers the WARN_ON(). And it most likely returns 0, because > its internal data structure for that CPU is not present. > > I *guess* that before the above commit policy was NULL in cpufreq_update_policy() > and we didn't get to the point where ->get() was called. I am not sure if that behavior should have changed at all.. Earlier we were clearing per-cpu cpufreq_cpu_data for offline CPUs and so policy would have been NULL for offline CPUs. Now that per-cpu variable isn't cleared, but cpufreq_cpu_get() does check if the CPU is part of policy->cpus or not, i.e. if it is offline. And so policy should still be NULL for offline CPUs. I think it might be related to what I chased down yesterday: http://marc.info/?l=linux-kernel&m=143633485824975&w=2 @Steven: Can you please give this a try ? -- viresh -- 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
