On Wed, Aug 27, 2014 at 4:07 PM, Viresh Kumar
> Some more prints inside cpufreq_get_policy() might take us closer..
I've time to continue this bug hunt again:
With more prints:
struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
{
struct cpufreq_policy *policy = NULL;
unsigned long flags;
if ( cpufreq_disabled() )
{
printk("RT test errror: cpufreq_disabled(), returning NULL\n");
return NULL;
}
if (cpu >= nr_cpu_ids)
{
printk("cpu > nr_cpu_ids\n");
return NULL;
}
if (!down_read_trylock(&cpufreq_rwsem))
{
printk("RT debug: down_read_trylock( &cpufreq_rwsem ) returned NULL\n");
return NULL;
}
<snip>
The down_read_trylock() fails, the other checks are fine.
If i'm understanding correctly, the cpufreq_rwsem locks the module
from being unloaded during critical sections while writing to CPU
speed etc?
Would that mean that an un-matched pair of down_read() up_write()
could cause the failure of changing CPU speed?
-Harry
www.openavproductions.com
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
