[PATCH v4 0/5] Add support for the ARMv8.2 Statistical Profiling Extension

[Will Deacon]

On Thu, Jun 22, 2017 at 10:56:40AM -0500, Kim Phillips wrote:
> On Wed, 21 Jun 2017 16:31:09 +0100
> Will Deacon <will.deacon at arm.com> wrote:
> 
> > On Thu, Jun 15, 2017 at 10:57:35AM -0500, Kim Phillips wrote:
> > > On Mon, 12 Jun 2017 11:20:48 -0500
> > > Kim Phillips <kim.phillips at arm.com> wrote:
> > > 
> > > > On Mon, 12 Jun 2017 12:08:23 +0100
> > > > Mark Rutland <mark.rutland at arm.com> wrote:
> > > > 
> > > > > On Mon, Jun 05, 2017 at 04:22:52PM +0100, Will Deacon wrote:
> > > > > > This is the sixth posting of the patches previously posted here:
> > > ...
> > > > > Kim, do you have any version of the userspace side that we could look
> > > > > at?
> > > > > 
> > > > > For review, it would be really helpful to have something that can poke
> > > > > the PMU, even if it's incomplete or lacking polish.
> > > > 
> > > > Here's the latest push, based on a a couple of prior versions of this
> > > > driver:
> > > > 
> > > > http://linux-arm.org/git?p=linux-kp.git;a=shortlog;h=refs/heads/armspev0.1
> > > > 
> > > > I don't seem to be able to get any SPE data output after rebasing on
> > > > this version of the driver.  Still don't know why at the moment...
> > > 
> > > Bisected to commit e38ba76deef "perf tools: force uncore events to
> > > system wide monitoring".  So, using record with specifying a -C
> > > <cpu> explicitly now produces SPE data, but only a couple of valid
> > > records at the beginning of each buffer; the rest is filled with
> > > PADding (0's).
> > > 
> > > I see Mark's latest comments have found a possible issue in the perf
> > > aux buffer handling code in the driver, and that the driver does some
> > > memset of padding (0's) itself; could that be responsible for the above
> > > behaviour?
> > 
> > Possibly. Do you know how big you're mapping the aux buffer
> 
> 4MiB.
> 
> > and what (if any) value you're passing as aux_watermark?
> 
> None passed, but it looks like 4KiB was used since the AUXTRACE size
> was 4MiB - 4KiB.
> 
> I'm not seeing the issue with a simple bts-based version I'm
> working on...yet.  We can revisit if I'm able to reproduce again; the
> problem could have been on the userspace side.
> 
> Meanwhile, when using fvp-base.dtb, my model setup stops booting the
> kernel after "smp: Bringing up secondary CPUs ...".  If I however take
> the second SPE node from fvp-base.dts and add it to my working device
> tree, I get this during the driver probe:
> 
> [    1.042063] arm_spe_pmu spe-pmu at 0: probed for CPUs 0-7 [max_record_sz 64, align 1, features 0xf]
> [    1.043582] arm_spe_pmu spe-pmu at 1: probed for CPUs 0-7 [max_record_sz 64, align 1, features 0xf]
> [    1.043631] genirq: Flags mismatch irq 6. 00004404 (arm_spe_pmu) vs. 00004404 (arm_spe_pmu)

Looks like you've screwed up your IRQ partitions, so you are effectively
registering the same device twice, which then blows up due to lack of shared
irqs.

Either remove one of the devices, or use IRQ partitions to restrict them
to unique sets of CPUs.

Will