On Thu, Mar 17, 2016 at 10:07 AM, Rafael J. Wysocki <[email protected]> wrote: > On Thursday, March 17, 2016 09:02:29 AM Josh Boyer wrote: >> Hello, > > Hi, > >> I have an Intel Atom based NUC that is producing the following >> backtraces on boot of Linus' tree as of last evening. This does not >> happen with a tree with top level commit 271ecc5253e2, but does happen >> when using the tree mentioned in the subject with top level commit >> 63e30271b04c. >> >> The first backtrace appears to be a warning because the intel_pstate >> driver is calling wrmsrl_on_cpu when interrupts are disabled? Not >> sure on that one. >> >> The second backtrace is a lockdep report. Both are from the same boot. > > OK, thanks for the report. > > Can you please try the patch below? > > I'm actually unsure if we can do that safely in general for Atom because > of the initialization, but that's what Core does anyway. > > Srinivas, Philippe, why exactly do we need the wrmsrl_on_cpu() in > atom_set_pstate()? core_set_pstate() uses wrmsrl() and seems to be doing > fine. > > --- > drivers/cpufreq/intel_pstate.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-pm/drivers/cpufreq/intel_pstate.c > =================================================================== > --- linux-pm.orig/drivers/cpufreq/intel_pstate.c > +++ linux-pm/drivers/cpufreq/intel_pstate.c > @@ -587,7 +587,7 @@ static void atom_set_pstate(struct cpuda > > val |= vid; > > - wrmsrl_on_cpu(cpudata->cpu, MSR_IA32_PERF_CTL, val); > + wrmsrl(MSR_IA32_PERF_CTL, val); > } > > static int silvermont_get_scaling(void) >
I applied this on top of commit 09fd671ccb24 and the backtrace and lockdep report both go away. So yes, this seems to clear up the issue. I tested it on a variety of different CPU types and didn't notice anything wrong on them either. josh
