![]() | |||||||||||
Messages in this thread |
> I'm feeling a bit overwhelmed by the voluminous output of this checker. > Especially as (directly at least) cpufreq doesn't touch vma's, or mmap's. the reporter doesn't have CONFIG_KALLSYMS_ALL enabled which gives sometimes misleading backtraces (should lockdep just enable KALLSYMS_ALL to get more useful bugreports?) the problem is this, there are 2 scenarios in this bug: One --- store_scaling_governor takes policy->lock and then calls __cpufreq_set_policy __cpufreq_set_policy calls __cpufreq_governor __cpufreq_governor calls __cpufreq_driver_target via cpufreq_governor_performance __cpufreq_driver_target calls lock_cpu_hotplug() (which takes the hotplug lock) Two --- cpufreq_stats_init lock_cpu_hotplug() and then calls cpufreq_stat_cpu_callback cpufreq_stat_cpu_callback calls cpufreq_update_policy cpufreq_update_policy takes the policy->lock so this looks like a real honest AB-BA deadlock to me... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2006-05-30 07:48 [from the cache] ©2003-2008 | |||||||||||