From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Failure to boot default Debian wheezy (pvops) kernel on 4.2-rc2 Date: Thu, 14 Mar 2013 15:44:37 +0000 Message-ID: References: <20120817130757.GD31903@phenom.dumpdata.com> <502E449B.2030502@eu.citrix.com> <20120817140028.GB8093@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk , Ian Campbell Cc: "xen-devel@lists.xen.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Thu, Mar 14, 2013 at 10:07 AM, George Dunlap wrote: > On Fri, Aug 17, 2012 at 3:00 PM, Konrad Rzeszutek Wilk > wrote: >> So that translates to MSR_K7_EVNTSEL0. >> >> And that should only been shown once. Is the perf trying to load >> the module over and over? > > So I've just tested this again with the latest wheezy kernel (3.2.0-4) > but this time taking a closer look, I see this near the first > instance: > > > [ 0.072397] Performance Events: Broken BIOS detected, complain to > your hardware vendor.^M > [ 0.076015] [Firmware Bug]: the BIOS has corrupted hw-PMU resources > (MSR c0010000 is 530076)^M > [ 0.080007] AMD PMU driver.^M > [ 0.082861] ------------[ cut here ]------------^M > [ 0.084019] WARNING: at > /build/buildd-linux_3.2.39-2-i386-4VFKqr/linux-3.2.39/arch/x86/xen/enlighten.c:738 > perf_events_lapic_init+0x28/0x29()^M > [ 0.088009] Hardware name: empty^M > [ 0.091294] Modules linked in:^M > [ 0.092268] Pid: 1, comm: swapper/0 Not tainted 3.2.0-4-686-pae #1 > Debian 3.2.39-2^M > [ 0.096009] Call Trace:^M > [ 0.098531] [] ? warn_slowpath_common+0x68/0x79^M > [ 0.100011] [] ? perf_events_lapic_init+0x28/0x29^M > [ 0.104012] [] ? warn_slowpath_null+0xd/0x10^M > [ 0.108011] [] ? perf_events_lapic_init+0x28/0x29^M > [ 0.112016] [] ? init_hw_perf_events+0x223/0x3b1^M > [ 0.116012] [] ? check_bugs+0x1d9/0x1d9^M > [ 0.120014] [] ? do_one_initcall+0x66/0x10e^M > [ 0.124012] [] ? kernel_init+0x79/0x131^M > [ 0.128012] [] ? start_kernel+0x32a/0x32a^M > [ 0.132013] [] ? kernel_thread_helper+0x6/0x10^M > [ 0.136020] ---[ end trace b828488e55b27a3e ]---^M > [ 0.140015] ... version: 0^M > [ 0.144011] ... bit width: 48^M > [ 0.148012] ... generic registers: 4^M > [ 0.152011] ... value mask: 0000ffffffffffff^M > [ 0.156013] ... max period: 00007fffffffffff^M > [ 0.160012] ... fixed-purpose events: 0^M > [ 0.164013] ... event mask: 000000000000000f^M > [ 0.168276] NMI watchdog enabled, takes one hw-pmu counter.^M > (XEN) traps.c:2495:d0 Domain attempted WRMSR 00000000c0010004 from > 0x0000ffff9af0c3ec to 0x0000fffb5adce6f0. > > So relating this back to the discussion about vpmu for guests, it > looks like maybe it's testing the performance counters, detecting that > they're broken, but for some reason not actually disabling the NMI > watchdog, and keeps on using them? I'm guessing that the problem is in arch/x86/kernel/cpu/perf_events.c:check_hw_exits(). It has two failures modes -- "bios_fail" and "msr_fail". It does that check where it tries to write and then read the perfcounter MSRs to see if they're functional; if that fails it will go to msr_fail and return false. However, *before* it does that check, it does some other checks which, if they fail, will jump right to bios_fail, missing that check out entirely. Really the "goto bios_fail" is wrong in all sorts of ways -- e.g., in the first loop, if it detects that condition early on, it will entirely miss other MSR checks. I might just propose a complete rewrite of that function... -George