On Thu, 2006-07-06 at 07:58 -0700, Tom London wrote:
After installing .2356 I get this each time I boot:
=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
S06cpuspeed/1620 is trying to acquire lock:
(dbs_mutex){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24
but task is already holding lock:
(cpucontrol){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24
which lock already depends on the new lock.
this patch should fix this one
make sure the cpu hotplug recursive mutex (yuck) is taken early in the
cpufreq codepaths to avoid a AB-BA deadlock.
Signed-off-by: Arjan van de Ven <arjan(a)linux.intel.com>
---
drivers/cpufreq/cpufreq.c | 4 ++++
1 file changed, 4 insertions(+)
Index: linux-2.6.18-rc1/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.18-rc1.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.18-rc1/drivers/cpufreq/cpufreq.c
@@ -423,6 +423,8 @@ static ssize_t store_scaling_governor (s
if (cpufreq_parse_governor(str_governor, &new_policy.policy,
&new_policy.governor))
return -EINVAL;
+ lock_cpu_hotplug();
+
/* Do not use cpufreq_set_policy here or the user_policy.max
will be wrongly overridden */
mutex_lock(&policy->lock);
@@ -432,6 +434,8 @@ static ssize_t store_scaling_governor (s
policy->user_policy.governor = policy->governor;
mutex_unlock(&policy->lock);
+ unlock_cpu_hotplug();
+
return ret ? ret : count;
}