Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932649AbcCRMhU (ORCPT ); Fri, 18 Mar 2016 08:37:20 -0400 Received: from mail-oi0-f41.google.com ([209.85.218.41]:35093 "EHLO mail-oi0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750811AbcCRMhQ (ORCPT ); Fri, 18 Mar 2016 08:37:16 -0400 MIME-Version: 1.0 In-Reply-To: <10670722.U2p4NnYGsS@vostro.rjw.lan> References: <1704778.QLUl50G1uZ@vostro.rjw.lan> <10670722.U2p4NnYGsS@vostro.rjw.lan> Date: Fri, 18 Mar 2016 08:37:15 -0400 X-Google-Sender-Auth: 8zZjWa70JMEwqme1Ty0ep0xxCmU Message-ID: Subject: Re: intel_pstate oopses and lockdep report with Linux v4.5-1822-g63e30271b04c From: Josh Boyer To: "Rafael J. Wysocki" Cc: Srinivas Pandruvada , Philippe Longepe , Len Brown , Viresh Kumar , Linux PM list , "Linux-Kernel@Vger. Kernel. Org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2441 Lines: 63 On Thu, Mar 17, 2016 at 8:20 PM, Rafael J. Wysocki wrote: > On Thursday, March 17, 2016 12:44:54 PM Josh Boyer wrote: >> On Thu, Mar 17, 2016 at 10:07 AM, Rafael J. Wysocki 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. > > The problems may show up during initialization and cleanup where one CPU > may be running code trying to configure a different one. In those cases > wrmsrl_on_cpu() needs to be used. > > Let me cut a patch taking that into account. OK. Happy to test when you have it ready. josh