On 5 August 2014 16:17, Prarit Bhargava <pra...@redhat.com> wrote:
> Nope, not a stupid question. After reproducing (finally!) yesterday I've been
> wondering the same thing.
Good to know that :)
> I've been looking into *exactly* this. On any platform where
> cpu_weight(affected_cpus) == 1 for a particular cpu this lockdep trace should
> happen.
> That's what I'm wondering too. I'm going to instrument the code to find out
> this morning. I'm wondering if this comes down to a lockdep class issue
> (perhaps lockdep puts globally defined locks like cpufreq_global_kobject in a
> different class?).
Maybe, I tried this Hack to make this somewhat similar to the other case
on my platform with just two CPUs:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6f02485..6b4abac 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -98,7 +98,7 @@ static DEFINE_MUTEX(cpufreq_governor_mutex);
bool have_governor_per_policy(void)
{
- return !!(cpufreq_driver->flags & CPUFREQ_HAVE_GOVERNOR_PER_POLICY);
+ return !(cpufreq_driver->flags & CPUFREQ_HAVE_GOVERNOR_PER_POLICY);
}
EXPORT_SYMBOL_GPL(have_governor_per_policy);
This should result in something similar to setting that per-policy-governor
flag (Actually I could have done that too :)), and I couldn't see that crash :(
That needs more investigation now, probably we can get some champ of
sysfs stuff like Tejun/Greg into discussion now..
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
