commit 2ed99e39cb9392312c100d9da591c20641c64d12
Author: Rafael J. Wysocki <email address hidden>
Date: Wed Mar 12 21:49:33 2014 +0100
cpufreq: Skip current frequency initialization for ->setpolicy drivers
After commit da60ce9f2fac (cpufreq: call cpufreq_driver->get() after
calling ->init()) __cpufreq_add_dev() sometimes fails for CPUs handled
by intel_pstate, because that driver may return 0 from its ->get()
callback if it has not run long enough to collect enough samples on the
given CPU. That didn't happen before commit da60ce9f2fac which added
policy->cur initialization to __cpufreq_add_dev() to help reduce code
duplication in other cpufreq drivers.
...
Already backported to 3.13 since 3.13.0-20.
Will investigate why we are suffering from the same problem for their kernel (3.13.0-43).
I found the following commit:
commit 2ed99e39cb93923 12c100d9da591c2 0641c64d12
Author: Rafael J. Wysocki <email address hidden>
Date: Wed Mar 12 21:49:33 2014 +0100
cpufreq: Skip current frequency initialization for ->setpolicy drivers
After commit da60ce9f2fac (cpufreq: call cpufreq_ driver- >get() after
calling ->init()) __cpufreq_add_dev() sometimes fails for CPUs handled
by intel_pstate, because that driver may return 0 from its ->get()
callback if it has not run long enough to collect enough samples on the
given CPU. That didn't happen before commit da60ce9f2fac which added
policy->cur initialization to __cpufreq_add_dev() to help reduce code
duplication in other cpufreq drivers.
...
Already backported to 3.13 since 3.13.0-20.
Will investigate why we are suffering from the same problem for their kernel (3.13.0-43).