Re: [BUG] Core2 cpu triggers hard lockup with perf test

[Jiri Olsa <jolsa@redhat.com>]

On Tue, Mar 01, 2016 at 10:17:03AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 29, 2016 at 10:12:08PM +0000, Liang, Kan wrote:
> 
> > In SDM "18.4.4.4 Re-configuring PEBS Facilities" it mentioned that
> > a quiescent period is needed between stopping the prior event counting and
> > setting up a new PEBS event when software needs to reconfigure PEBS facilities.
> > The quiescent period is to allow any latent residual PEBS records to complete
> > its capture at their previously specified buffer address
> 
> > That requirement only can be found in Core Microarchitecture. 
> 
> But that should apply to all (PEBS) event scheduling, not just the
> multi thing.
> 
> Also very convenient that quiescent period is so well defined. How long
> should we wait, a day?
> 
> > I think it may implies that there is some observed delay in writing PEBS buffer.
> 
> Doesn't it explicitly state just that?
> 
> > So if perf record precise hw event with very small period, the slow PEBS writing
> > may lockup the CPU. 
> 
> And I still don't see how this would explain a lockup in the MSR writes.
> 
> [ Jiri, can you disable that stupid panic on hard lockup and let it run
> for a while, see if all the lockup msgs hit the same IP? Also, can you
> look where exactly that IP lives in the code? ]

im on it.. also the patch that makes this happen just
enlarge the buffer for PEBS:

  156174999dd1 perf/intel/x86: Enlarge the PEBS buffer

but I did not find anyaPEBS buffer lenght limitations in SDM

jirka

> 
> So I suspect it actually just did the PERF_GLOBAL_CTRL write, how else
> would the hardware watchdog trigger on that same CPU.
> 
> After that, there's only BTS muck, which you're not using, so WTH is it
> actually stuck on?
> 
> > If so, I think disabling the multiple pebs should be a good way.
> 
> As said, this should affect any and all PEBS event scheduling, not just
> the multi stuff.