On 12 September 2013 00:12, Srivatsa S. Bhat
<srivatsa.bhat@xxxxxxxxxxxxxxxxxx> wrote:
> OK, I took a second look at the code, and I suspect that applying the
> second patch might help. So can you try by applying both the patches
> please[1][2]?
>
> Basically here is my hunch: say CPUs 2 and 3 are part of a policy and
> 3 is the policy->cpu. During suspend, CPU 2 will be taken offline first,
> and we hit this code:
>
> 1199 if (cpu != policy->cpu && !frozen) {
> 1200 sysfs_remove_link(&dev->kobj, "cpufreq");
> 1201 } else if (cpus > 1) {
> 1202
> 1203 new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu, frozen);
> 1204 if (new_cpu >= 0) {
> 1205 WARN_ON(lock_policy_rwsem_write(cpu));
> 1206 update_policy_cpu(policy, new_cpu);
> 1207 unlock_policy_rwsem_write(cpu);
> 1208
> 1209 if (!frozen) {
> 1210 pr_debug("%s: policy Kobject moved to cpu: %d "
> 1211 "from: %d\n",__func__, new_cpu, cpu);
> 1212 }
> 1213 }
> 1214 }
>
> At this point, the first 'if' condition fails because frozen == true.
> So it enters the else part. But, policy->cpu is actually 3, not 2,
> and hence we invoke nominate_...() unnecessarily. That function returns
> 3 since that's the only CPU remaining in the mask, and so we call
> update_policy_cpu() with new_cpu = 3, and old_cpu was also 3! And that
> is the perfect recipe for disaster, with the current implementation of
> update_policy_cpu().
The problem here is not the wrong implementation of update_policy_cpu()
but
1199 if (cpu != policy->cpu && !frozen) {
Though I have fixed it before looking into your replies :)
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
