* [PATCH 00/14] arm_pmu: ACPI support
@ 2017-03-17 2:11 Itaru Kitayama
2017-03-23 10:54 ` Mark Rutland
0 siblings, 1 reply; 23+ messages in thread
From: Itaru Kitayama @ 2017-03-17 2:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mark,
I've tried your branch on Mustang. It does boot, but perf doesn't list
hardware events.
Are you going to try it out on Mustang as well? In Linaro Colo, the FW
is 3.06.25.
Itaru
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-17 2:11 [PATCH 00/14] arm_pmu: ACPI support Itaru Kitayama
@ 2017-03-23 10:54 ` Mark Rutland
2017-03-25 3:18 ` Itaru Kitayama
0 siblings, 1 reply; 23+ messages in thread
From: Mark Rutland @ 2017-03-23 10:54 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 17, 2017 at 11:11:47AM +0900, Itaru Kitayama wrote:
> Hi Mark,
Hi,
> I've tried your branch on Mustang. It does boot, but perf doesn't
> list hardware events.
Can you please dump the dmesg here?
What exactly do you see if you run:
$ perf list
> Are you going to try it out on Mustang as well? In Linaro Colo, the
> FW is 3.06.25.
As mentioned in [1], I tried the patches on an APM Mustang platform, and
PMU events worked as expected. I had a local workaround for an FW bug,
but this shouldn't have affected the PMU.
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/493808.html
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-23 10:54 ` Mark Rutland
@ 2017-03-25 3:18 ` Itaru Kitayama
0 siblings, 0 replies; 23+ messages in thread
From: Itaru Kitayama @ 2017-03-25 3:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mark,
On 2017/03/23 19:54, Mark Rutland wrote:
> On Fri, Mar 17, 2017 at 11:11:47AM +0900, Itaru Kitayama wrote:
>> I've tried your branch on Mustang. It does boot, but perf doesn't
>> list hardware events.
>
> Can you please dump the dmesg here?
I think this time I booted into correctly the kernel based upon your
branch and got a proper set of events.
> What exactly do you see if you run:
>
> $ perf list
branch-misses [Hardware event]
cache-misses [Hardware event]
cache-references [Hardware event]
cpu-cycles OR cycles [Hardware event]
instructions [Hardware event]
alignment-faults [Software event]
bpf-output [Software event]
context-switches OR cs [Software event]
cpu-clock [Software event]
cpu-migrations OR migrations [Software event]
dummy [Software event]
emulation-faults [Software event]
major-faults [Software event]
minor-faults [Software event]
page-faults OR faults [Software event]
task-clock [Software event]
L1-dcache-load-misses [Hardware cache event]
L1-dcache-loads [Hardware cache event]
L1-dcache-store-misses [Hardware cache event]
L1-dcache-stores [Hardware cache event]
L1-icache-load-misses [Hardware cache event]
L1-icache-loads [Hardware cache event]
branch-load-misses [Hardware cache event]
branch-loads [Hardware cache event]
dTLB-load-misses [Hardware cache event]
iTLB-load-misses [Hardware cache event]
armv8_pmuv3_0/br_mis_pred/ [Kernel PMU event]
armv8_pmuv3_0/br_pred/ [Kernel PMU event]
armv8_pmuv3_0/bus_access/ [Kernel PMU event]
armv8_pmuv3_0/cid_write_retired/ [Kernel PMU event]
armv8_pmuv3_0/cpu_cycles/ [Kernel PMU event]
armv8_pmuv3_0/exc_return/ [Kernel PMU event]
armv8_pmuv3_0/exc_taken/ [Kernel PMU event]
armv8_pmuv3_0/inst_retired/ [Kernel PMU event]
armv8_pmuv3_0/inst_spec/ [Kernel PMU event]
armv8_pmuv3_0/l1d_cache/ [Kernel PMU event]
armv8_pmuv3_0/l1d_cache_refill/ [Kernel PMU event]
armv8_pmuv3_0/l1d_cache_wb/ [Kernel PMU event]
armv8_pmuv3_0/l1d_tlb_refill/ [Kernel PMU event]
armv8_pmuv3_0/l1i_cache/ [Kernel PMU event]
armv8_pmuv3_0/l1i_cache_refill/ [Kernel PMU event]
armv8_pmuv3_0/l1i_tlb_refill/ [Kernel PMU event]
armv8_pmuv3_0/l2d_cache/ [Kernel PMU event]
armv8_pmuv3_0/l2d_cache_refill/ [Kernel PMU event]
armv8_pmuv3_0/l2d_cache_wb/ [Kernel PMU event]
armv8_pmuv3_0/mem_access/ [Kernel PMU event]
armv8_pmuv3_0/memory_error/ [Kernel PMU event]
armv8_pmuv3_0/sw_incr/ [Kernel PMU event]
armv8_pmuv3_0/ttbr_write_retired/ [Kernel PMU event]
rNNN [Raw hardware
event descriptor]
cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware
event descriptor]
mem:<addr>[/len][:access] [Hardwarebreakpoint]
I've verified this on an APM Mustang with the FW 3.06.25.
Itaru
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-20 18:11 ` Ganapatrao Kulkarni
2017-03-22 9:16 ` Ganapatrao Kulkarni
@ 2017-04-11 9:32 ` Hanjun Guo
1 sibling, 0 replies; 23+ messages in thread
From: Hanjun Guo @ 2017-04-11 9:32 UTC (permalink / raw)
To: linux-arm-kernel
On 2017/3/21 2:11, Ganapatrao Kulkarni wrote:
> Hi Hanjun,
>
> On Thu, Mar 16, 2017 at 6:30 PM, Hanjun Guo <guohanjun@huawei.com> wrote:
>> On 2017/3/10 19:04, Mark Rutland wrote:
>>> Hi,
>>>
>>> This series implements ACPI support in the ARM PMU code. It borrows some code
>>> from Jeremy's series [1], but takes a different approach to probing and
>>> association, using the usual hotplug state machine, minimising external changes
>>> required, and simplifying the relationship with the common arm_pmu code.
>>>
>>> The first few patches are preparatory cleanup/refactoring, with the latter half
>>> of the series being specific to ACPI support.
>>>
>>> The series is based on my IRQ rework patches [2]. I've pushed the whole series
>>> out to the arm/perf/acpi branch [3] of my kernel.org repo.
>>>
>>> Due to the innards of the hotplug callback framework, it's not entirely
>>> safe to register a PMU in a hotplug callback. Due to this, we can only
>>> associated hotplugged CPUs with a PMU if a matching CPU was around at
>>> probe time. A similar restriction already applies to DT systems. We may
>>> be able to relax this with some future work.
>>>
>>> I've given this some testing on a Juno platform (using SPIs). To see that IRQs
>>> are correctly associated, I've tested with the following:
>>>
>>> $ taskset -c ${SOME_CPU_HERE} perf record \
>>> -e armv8_pmuv3_0/cpu_cycles/ \
>>> -e armv8_pmuv3_1/cpu_cycles/ \
>>> cat /proc/interrupts
>>>
>>> I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the
>>> association logic. This has also been tested in a VM using PPIs; I do not have
>>> access to a host machine which itself uses PPIs.
>> Booted OK and 'perf list' got on Hisilicon D03:
>>
>> d03-09:~ # perf list
>>
>> List of pre-defined events (to be used in -e):
>>
>> branch-misses [Hardware event]
>> bus-cycles [Hardware event]
>> cache-misses [Hardware event]
>> cache-references [Hardware event]
>> cpu-cycles OR cycles [Hardware event]
>> instructions [Hardware event]
>>
>> alignment-faults [Software event]
>> context-switches OR cs [Software event]
>> cpu-clock [Software event]
>> cpu-migrations OR migrations [Software event]
>> dummy [Software event]
>> emulation-faults [Software event]
>> major-faults [Software event]
>> minor-faults [Software event]
>> page-faults OR faults [Software event]
>> task-clock [Software event]
>>
>> L1-dcache-load-misses [Hardware cache event]
>> L1-dcache-loads [Hardware cache event]
>> L1-dcache-store-misses [Hardware cache event]
>> L1-dcache-stores [Hardware cache event]
>> L1-icache-load-misses [Hardware cache event]
>> L1-icache-loads [Hardware cache event]
>> branch-load-misses [Hardware cache event]
>> branch-loads [Hardware cache event]
>> dTLB-load-misses [Hardware cache event]
>> iTLB-load-misses [Hardware cache event]
>>
>> armv8_pmuv3_0/br_mis_pred/ [Kernel PMU event]
>> armv8_pmuv3_0/br_pred/ [Kernel PMU event]
>> armv8_pmuv3_0/bus_access/ [Kernel PMU event]
>> armv8_pmuv3_0/bus_cycles/ [Kernel PMU event]
>> armv8_pmuv3_0/cid_write_retired/ [Kernel PMU event]
>> armv8_pmuv3_0/cpu_cycles/ [Kernel PMU event]
>> armv8_pmuv3_0/exc_return/ [Kernel PMU event]
>> armv8_pmuv3_0/exc_taken/ [Kernel PMU event]
>> armv8_pmuv3_0/inst_retired/ [Kernel PMU event]
>> armv8_pmuv3_0/inst_spec/ [Kernel PMU event]
>> armv8_pmuv3_0/l1d_cache/ [Kernel PMU event]
>> armv8_pmuv3_0/l1d_cache_refill/ [Kernel PMU event]
>> armv8_pmuv3_0/l1d_cache_wb/ [Kernel PMU event]
>> armv8_pmuv3_0/l1d_tlb_refill/ [Kernel PMU event]
>> armv8_pmuv3_0/l1i_cache/ [Kernel PMU event]
>> armv8_pmuv3_0/l1i_cache_refill/ [Kernel PMU event]
>> armv8_pmuv3_0/l1i_tlb_refill/ [Kernel PMU event]
>> armv8_pmuv3_0/l2d_cache/ [Kernel PMU event]
>> armv8_pmuv3_0/l2d_cache_refill/ [Kernel PMU event]
>> armv8_pmuv3_0/l2d_cache_wb/ [Kernel PMU event]
>> armv8_pmuv3_0/mem_access/ [Kernel PMU event]
>> armv8_pmuv3_0/memory_error/ [Kernel PMU event]
>> armv8_pmuv3_0/sw_incr/ [Kernel PMU event]
>> armv8_pmuv3_0/ttbr_write_retired/ [Kernel PMU event]
>>
>> rNNN [Raw hardware event descriptor]
>> cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor]
>> (see 'man perf-list' on how to encode it)
>>
>> mem:<addr>[/len][:access] [Hardware breakpoint]
>>
>>
>> Try some basic perf event and it works, anything else I can try in specific?
> you can try perf fuzzer
Sorry, just back from my paternity leave, I will try Mark's v2 (or v3 if there is a
updated one) :)
Thanks
Hanjun
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-04-03 10:41 ` Ganapatrao Kulkarni
@ 2017-04-03 11:12 ` Mark Rutland
0 siblings, 0 replies; 23+ messages in thread
From: Mark Rutland @ 2017-04-03 11:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Mon, Apr 03, 2017 at 04:11:42PM +0530, Ganapatrao Kulkarni wrote:
> On Wed, Mar 22, 2017 at 2:46 PM, Ganapatrao Kulkarni
> <gpkulkarni@gmail.com> wrote:
> > i am not able to run with latest perf tool, i see issue with memory
> > corruption in malloc
> > is this seen from anyone else too?
> > i am not sure, is this issue with my setup?
> >
> > root at VAL1-13>perf>> perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1
> >
> > Performance counter stats for 'sleep 1':
> >
> > 10,815 armv8_pmuv3_0/br_mis_pred/
> >
> > 1.001232167 seconds time elapsed
> >
> > root at VAL1-13>perf>> ./perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1
> > *** Error in `./perf': free(): invalid next size (fast): 0x00000000086a7a00 ***
> > Aborted (core dumped)
> > root at VAL1-13>perf>> ./perf -v
> > perf version 4.11.rc3.g093b99
> > root at VAL1-13>perf>> perf -v
> > perf version 4.8.rc6.g21c488
> > root at VAL1-13>perf>> uname -a
> > Linux VAL1-13 4.11.0-rc2-12139-g3804e12 #1 SMP PREEMPT Wed Mar 22
> > 06:26:28 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
> > root at VAL1-13>perf>>
>
> i did bisect, and i see your patch,
>
> 7e3fcffe955440101493cd8f32f75840ddf87b6f
> perf pmu: Support alternative sysfs cpumask
>
> is causing this failure. if i suppress the call to function cpu_map__read
> then memory corruption is not seen.
Thanks for tracking this down.
I can reproduce this on some machines; I'll try to see how this can be
fixed shortly.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-22 9:16 ` Ganapatrao Kulkarni
2017-03-22 15:59 ` Mark Rutland
@ 2017-04-03 10:41 ` Ganapatrao Kulkarni
2017-04-03 11:12 ` Mark Rutland
1 sibling, 1 reply; 23+ messages in thread
From: Ganapatrao Kulkarni @ 2017-04-03 10:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mark,
On Wed, Mar 22, 2017 at 2:46 PM, Ganapatrao Kulkarni
<gpkulkarni@gmail.com> wrote:
> i am not able to run with latest perf tool, i see issue with memory
> corruption in malloc
> is this seen from anyone else too?
> i am not sure, is this issue with my setup?
>
> root at VAL1-13>perf>> perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1
>
> Performance counter stats for 'sleep 1':
>
> 10,815 armv8_pmuv3_0/br_mis_pred/
>
> 1.001232167 seconds time elapsed
>
> root at VAL1-13>perf>> ./perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1
> *** Error in `./perf': free(): invalid next size (fast): 0x00000000086a7a00 ***
> Aborted (core dumped)
> root at VAL1-13>perf>> ./perf -v
> perf version 4.11.rc3.g093b99
> root at VAL1-13>perf>> perf -v
> perf version 4.8.rc6.g21c488
> root at VAL1-13>perf>> uname -a
> Linux VAL1-13 4.11.0-rc2-12139-g3804e12 #1 SMP PREEMPT Wed Mar 22
> 06:26:28 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
> root at VAL1-13>perf>>
>
i did bisect, and i see your patch,
7e3fcffe955440101493cd8f32f75840ddf87b6f
perf pmu: Support alternative sysfs cpumask
is causing this failure. if i suppress the call to function cpu_map__read
then memory corruption is not seen.
>
> On Mon, Mar 20, 2017 at 11:41 PM, Ganapatrao Kulkarni
> <gpkulkarni@gmail.com> wrote:
>> Hi Hanjun,
>>
>> On Thu, Mar 16, 2017 at 6:30 PM, Hanjun Guo <guohanjun@huawei.com> wrote:
>>> On 2017/3/10 19:04, Mark Rutland wrote:
>>>> Hi,
>>>>
>>>> This series implements ACPI support in the ARM PMU code. It borrows some code
>>>> from Jeremy's series [1], but takes a different approach to probing and
>>>> association, using the usual hotplug state machine, minimising external changes
>>>> required, and simplifying the relationship with the common arm_pmu code.
>>>>
>>>> The first few patches are preparatory cleanup/refactoring, with the latter half
>>>> of the series being specific to ACPI support.
>>>>
>>>> The series is based on my IRQ rework patches [2]. I've pushed the whole series
>>>> out to the arm/perf/acpi branch [3] of my kernel.org repo.
>>>>
>>>> Due to the innards of the hotplug callback framework, it's not entirely
>>>> safe to register a PMU in a hotplug callback. Due to this, we can only
>>>> associated hotplugged CPUs with a PMU if a matching CPU was around at
>>>> probe time. A similar restriction already applies to DT systems. We may
>>>> be able to relax this with some future work.
>>>>
>>>> I've given this some testing on a Juno platform (using SPIs). To see that IRQs
>>>> are correctly associated, I've tested with the following:
>>>>
>>>> $ taskset -c ${SOME_CPU_HERE} perf record \
>>>> -e armv8_pmuv3_0/cpu_cycles/ \
>>>> -e armv8_pmuv3_1/cpu_cycles/ \
>>>> cat /proc/interrupts
>>>>
>>>> I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the
>>>> association logic. This has also been tested in a VM using PPIs; I do not have
>>>> access to a host machine which itself uses PPIs.
>>>
>>> Booted OK and 'perf list' got on Hisilicon D03:
>>>
>>> d03-09:~ # perf list
>>>
>>> List of pre-defined events (to be used in -e):
>>>
>>> branch-misses [Hardware event]
>>> bus-cycles [Hardware event]
>>> cache-misses [Hardware event]
>>> cache-references [Hardware event]
>>> cpu-cycles OR cycles [Hardware event]
>>> instructions [Hardware event]
>>>
>>> alignment-faults [Software event]
>>> context-switches OR cs [Software event]
>>> cpu-clock [Software event]
>>> cpu-migrations OR migrations [Software event]
>>> dummy [Software event]
>>> emulation-faults [Software event]
>>> major-faults [Software event]
>>> minor-faults [Software event]
>>> page-faults OR faults [Software event]
>>> task-clock [Software event]
>>>
>>> L1-dcache-load-misses [Hardware cache event]
>>> L1-dcache-loads [Hardware cache event]
>>> L1-dcache-store-misses [Hardware cache event]
>>> L1-dcache-stores [Hardware cache event]
>>> L1-icache-load-misses [Hardware cache event]
>>> L1-icache-loads [Hardware cache event]
>>> branch-load-misses [Hardware cache event]
>>> branch-loads [Hardware cache event]
>>> dTLB-load-misses [Hardware cache event]
>>> iTLB-load-misses [Hardware cache event]
>>>
>>> armv8_pmuv3_0/br_mis_pred/ [Kernel PMU event]
>>> armv8_pmuv3_0/br_pred/ [Kernel PMU event]
>>> armv8_pmuv3_0/bus_access/ [Kernel PMU event]
>>> armv8_pmuv3_0/bus_cycles/ [Kernel PMU event]
>>> armv8_pmuv3_0/cid_write_retired/ [Kernel PMU event]
>>> armv8_pmuv3_0/cpu_cycles/ [Kernel PMU event]
>>> armv8_pmuv3_0/exc_return/ [Kernel PMU event]
>>> armv8_pmuv3_0/exc_taken/ [Kernel PMU event]
>>> armv8_pmuv3_0/inst_retired/ [Kernel PMU event]
>>> armv8_pmuv3_0/inst_spec/ [Kernel PMU event]
>>> armv8_pmuv3_0/l1d_cache/ [Kernel PMU event]
>>> armv8_pmuv3_0/l1d_cache_refill/ [Kernel PMU event]
>>> armv8_pmuv3_0/l1d_cache_wb/ [Kernel PMU event]
>>> armv8_pmuv3_0/l1d_tlb_refill/ [Kernel PMU event]
>>> armv8_pmuv3_0/l1i_cache/ [Kernel PMU event]
>>> armv8_pmuv3_0/l1i_cache_refill/ [Kernel PMU event]
>>> armv8_pmuv3_0/l1i_tlb_refill/ [Kernel PMU event]
>>> armv8_pmuv3_0/l2d_cache/ [Kernel PMU event]
>>> armv8_pmuv3_0/l2d_cache_refill/ [Kernel PMU event]
>>> armv8_pmuv3_0/l2d_cache_wb/ [Kernel PMU event]
>>> armv8_pmuv3_0/mem_access/ [Kernel PMU event]
>>> armv8_pmuv3_0/memory_error/ [Kernel PMU event]
>>> armv8_pmuv3_0/sw_incr/ [Kernel PMU event]
>>> armv8_pmuv3_0/ttbr_write_retired/ [Kernel PMU event]
>>>
>>> rNNN [Raw hardware event descriptor]
>>> cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor]
>>> (see 'man perf-list' on how to encode it)
>>>
>>> mem:<addr>[/len][:access] [Hardware breakpoint]
>>>
>>>
>>> Try some basic perf event and it works, anything else I can try in specific?
>>
>> you can try perf fuzzer
>>
>> thanks
>> Ganapat
>>
>>>
>>> Thanks
>>> Hanjun
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> thanks
> Ganapat
thanks
Ganapat
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-28 11:31 ` Mark Rutland
@ 2017-03-28 14:41 ` Jeremy Linton
0 siblings, 0 replies; 23+ messages in thread
From: Jeremy Linton @ 2017-03-28 14:41 UTC (permalink / raw)
To: linux-arm-kernel
On 03/28/2017 06:31 AM, Mark Rutland wrote:
> Hi Jeremy,
>
> On Fri, Mar 24, 2017 at 04:36:34PM -0500, Jeremy Linton wrote:
>> I've been testing these on a few machines (m400 & dual socket cavium
>> for starters) over the last few days. So far everything seems to be
>> working fine excepting the usual set of strange messages from the
>> perf fuzzer.
>>
>> Tested-by: Jeremy Linton <jlinton@arm.com>
>
> Thanks for giving this a go, especially with the fuzzer!
>
> Just to check, should that email be jeremy.linton at arm.com, or is that an
> alias that also works? I've added it as-is for the moment.
Yes, my fingers tend to out type my brain on a regular basis,
particularly when context switching between things.
jeremy.linton at arm.com is correct.
Thanks,
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-24 21:36 ` Jeremy Linton
@ 2017-03-28 11:31 ` Mark Rutland
2017-03-28 14:41 ` Jeremy Linton
0 siblings, 1 reply; 23+ messages in thread
From: Mark Rutland @ 2017-03-28 11:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jeremy,
On Fri, Mar 24, 2017 at 04:36:34PM -0500, Jeremy Linton wrote:
> I've been testing these on a few machines (m400 & dual socket cavium
> for starters) over the last few days. So far everything seems to be
> working fine excepting the usual set of strange messages from the
> perf fuzzer.
>
> Tested-by: Jeremy Linton <jlinton@arm.com>
Thanks for giving this a go, especially with the fuzzer!
Just to check, should that email be jeremy.linton at arm.com, or is that an
alias that also works? I've added it as-is for the moment.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-10 11:04 Mark Rutland
2017-03-10 22:14 ` Jeremy Linton
2017-03-16 13:00 ` Hanjun Guo
@ 2017-03-24 21:36 ` Jeremy Linton
2017-03-28 11:31 ` Mark Rutland
2 siblings, 1 reply; 23+ messages in thread
From: Jeremy Linton @ 2017-03-24 21:36 UTC (permalink / raw)
To: linux-arm-kernel
On 03/10/2017 05:04 AM, Mark Rutland wrote:
> Hi,
>
> This series implements ACPI support in the ARM PMU code. It borrows some code
> from Jeremy's series [1], but takes a different approach to probing and
> association, using the usual hotplug state machine, minimising external changes
> required, and simplifying the relationship with the common arm_pmu code.
>
> The first few patches are preparatory cleanup/refactoring, with the latter half
> of the series being specific to ACPI support.
>
> The series is based on my IRQ rework patches [2]. I've pushed the whole series
> out to the arm/perf/acpi branch [3] of my kernel.org repo.
>
> Due to the innards of the hotplug callback framework, it's not entirely
> safe to register a PMU in a hotplug callback. Due to this, we can only
> associated hotplugged CPUs with a PMU if a matching CPU was around at
> probe time. A similar restriction already applies to DT systems. We may
> be able to relax this with some future work.
>
> I've given this some testing on a Juno platform (using SPIs). To see that IRQs
> are correctly associated, I've tested with the following:
>
> $ taskset -c ${SOME_CPU_HERE} perf record \
> -e armv8_pmuv3_0/cpu_cycles/ \
> -e armv8_pmuv3_1/cpu_cycles/ \
> cat /proc/interrupts
>
> I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the
> association logic. This has also been tested in a VM using PPIs; I do not have
> access to a host machine which itself uses PPIs.
>
> Thanks,
> Mark.
I've been testing these on a few machines (m400 & dual socket cavium for
starters) over the last few days. So far everything seems to be working
fine excepting the usual set of strange messages from the perf fuzzer.
Tested-by: Jeremy Linton <jlinton@arm.com>
Thanks,
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/482397.html
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492891.html
> [3] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm/perf/acpi
>
> Mark Rutland (14):
> drivers/perf: arm_pmu: remove pointless PMU disabling
> drivers/perf: arm_pmu: define armpmu_init_fn
> drivers/perf: arm_pmu: fold init into alloc
> drivers/perf: arm_pmu: factor out pmu registration
> drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs()
> drivers/perf: arm_pmu: handle no platform_device
> drivers/perf: arm_pmu: rename irq request/free functions
> drivers/perf: arm_pmu: split cpu-local irq request/free
> drivers/perf: arm_pmu: move irq request/free into probe
> drivers/perf: arm_pmu: split out platform device probe logic
> arm64: add function to get a cpu's MADT GICC table
> arm64: kill acpi_set_mailbox_entry()
> drivers/perf: arm_pmu: add ACPI framework
> arm64: pmuv3: use arm_pmu ACPI framework
>
> arch/arm64/include/asm/acpi.h | 7 +-
> arch/arm64/kernel/acpi_parking_protocol.c | 38 +--
> arch/arm64/kernel/perf_event.c | 26 +-
> arch/arm64/kernel/smp.c | 19 +-
> drivers/perf/Kconfig | 4 +
> drivers/perf/Makefile | 3 +-
> drivers/perf/arm_pmu.c | 383 ++++++++----------------------
> drivers/perf/arm_pmu_acpi.c | 237 ++++++++++++++++++
> drivers/perf/arm_pmu_platform.c | 235 ++++++++++++++++++
> include/linux/cpuhotplug.h | 1 +
> include/linux/perf/arm_pmu.h | 22 +-
> 11 files changed, 626 insertions(+), 349 deletions(-)
> create mode 100644 drivers/perf/arm_pmu_acpi.c
> create mode 100644 drivers/perf/arm_pmu_platform.c
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-22 12:19 ` Lorenzo Pieralisi
2017-03-22 14:06 ` Agustin Vega-Frias
@ 2017-03-22 23:23 ` Hanjun Guo
1 sibling, 0 replies; 23+ messages in thread
From: Hanjun Guo @ 2017-03-22 23:23 UTC (permalink / raw)
To: linux-arm-kernel
On 03/22/2017 08:19 PM, Lorenzo Pieralisi wrote:
> On Tue, Mar 14, 2017 at 06:47:34PM +0000, Mark Rutland wrote:
>> On Tue, Mar 14, 2017 at 11:49:19AM +0000, Mark Rutland wrote:
>>> On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote:
>>>> I tried these patches on a m400 (which uses PPIs), and the kernel
>>>> fails to come up enough to login via the network (which works with
>>>> 4.11rc1 without these patches). So, I suspect there is something
>>>> wrong with them.
>>>
>>> Indeed; sorry about this. I'll see if I can get access to a board to try
>>> local debugging.
>>
>>>> About the only thing it says with any meaning when earlycon is passed is:
>>>> [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
>>>> [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq
>>>>
>>>> and promptly hangs up.
>>
>> I believe that this is a latent FW bug, in a beta FW, exposed by recent
>> changes.
>>
>> I managed to get access to two APM Mustang boards. I can reproduce the
>> issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW.
>> The same kernel boots fine on the other, which has a later released FW.
>>
>> I bisected the issue down to commit:
>>
>> d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain mapping")
>>
>> It seems the beta FW describes the UART interrupt with an Extended
>> Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec,
>> this means "This device produces and consumes this resource", which
>> doesn't make sense here given the UART is not an interrupt controller.
>>
>> The (working) released FW doesn't use an Extended Interrupt Descriptor
>> for this interrupt, sidestepping the issue.
>>
>> Given that (AFAICT) this only affects a known-broken, beta FW, I don't
>> think that we care that much.
>>
>> However, I think there is a larger potential issue here.
>>
>> In acpi_irq_parse_one_cb(), we skip interrupts with an Extended
>> Interrupt Descriptor with the Consumer/Producer bit clear. It sounds
>> like devices which behave as interrupt controllers could legitimately
>> have this bit set for interrupts they generate and deliver to
>> themselves, and we'd erroneously skip these when parsing interrupts.
>>
>> It's not entirely clear to me why this bit exists at all, given that
>> it's not used as part of mapping the interrupt, and if you really want
>> to know you can map the interrupt and look at the result.
>
> It is not entirely clear to anyone (and it has been a source of major
> trouble for other descriptors - ie memory - to the point that it has been
> deprecated for *some* descriptors). IIRC (Hanjun ?) the only reason why
> Agustin added the check for that bit in drivers/acpi/resource.c
> (is_gsi()) is to prevent ACPI core code allocating IRQs for the MBIgen
> device that, _erroneously_, was using an extended interrupt descriptor
> to list IRQ lines (that I have no idea what they represent) in order to
> count how many MSI vectors it would have to allocate.
I'm not sure it's error for a interrupt producer device (such as MBIgen)
to represent its interrupt resources using Interrupt under _CRS, from
the spec, we didn't violate anything, but in the OS side we expect a
better way to count MSI vectors.
>
> The gist is: removing the check for the extended interrupt descriptor
> producer/consumer bit in ACPI code therefore ignoring that bit should
> be harmless (given that the MBIgen bindings should be changed anyway).
>
> The meaning of that bit (and how we can flag up a FW bug) it is still
> a bit fuzzy IMO.
>
> Agustin, Hanjun, comments ?
I think it's firmware bug in the first place, PRODUCER bit can't be
clear if the device itself is not an interrupt controller, as we
can see that it's UART interrupt and UART can't be a interrupt
controller right? and the default value for the Consumer/Producer bit
is 1, not 0, the spec clearly say that.
So I think we need to fix the firmware (then the code is still not
violate any platforms), and also we need to fix the spec to clarify
things (As Agustin proposed), I reported this issue to ASWG but seems
my email was blocked, I will raise an ECR for discussion.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-22 9:16 ` Ganapatrao Kulkarni
@ 2017-03-22 15:59 ` Mark Rutland
2017-04-03 10:41 ` Ganapatrao Kulkarni
1 sibling, 0 replies; 23+ messages in thread
From: Mark Rutland @ 2017-03-22 15:59 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 22, 2017 at 02:46:50PM +0530, Ganapatrao Kulkarni wrote:
> i am not able to run with latest perf tool, i see issue with memory
> corruption in malloc
> is this seen from anyone else too?
> i am not sure, is this issue with my setup?
>
> root at VAL1-13>perf>> perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1
>
> Performance counter stats for 'sleep 1':
>
> 10,815 armv8_pmuv3_0/br_mis_pred/
>
> 1.001232167 seconds time elapsed
>
> root at VAL1-13>perf>> ./perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1
> *** Error in `./perf': free(): invalid next size (fast): 0x00000000086a7a00 ***
> Aborted (core dumped)
> root at VAL1-13>perf>> ./perf -v
> perf version 4.11.rc3.g093b99
> root at VAL1-13>perf>> perf -v
> perf version 4.8.rc6.g21c488
> root at VAL1-13>perf>> uname -a
> Linux VAL1-13 4.11.0-rc2-12139-g3804e12 #1 SMP PREEMPT Wed Mar 22
> 06:26:28 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
> root at VAL1-13>perf>>
I've managed to reproduce this on a Seatle system using DT, with the
perf tool from v4.11-rc3.
I'm digging into this now.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-22 12:19 ` Lorenzo Pieralisi
@ 2017-03-22 14:06 ` Agustin Vega-Frias
2017-03-22 23:23 ` Hanjun Guo
1 sibling, 0 replies; 23+ messages in thread
From: Agustin Vega-Frias @ 2017-03-22 14:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lorenzo,
On 2017-03-22 08:19, Lorenzo Pieralisi wrote:
> On Tue, Mar 14, 2017 at 06:47:34PM +0000, Mark Rutland wrote:
>> On Tue, Mar 14, 2017 at 11:49:19AM +0000, Mark Rutland wrote:
>> > On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote:
>> > > I tried these patches on a m400 (which uses PPIs), and the kernel
>> > > fails to come up enough to login via the network (which works with
>> > > 4.11rc1 without these patches). So, I suspect there is something
>> > > wrong with them.
>> >
>> > Indeed; sorry about this. I'll see if I can get access to a board to try
>> > local debugging.
>>
>> > > About the only thing it says with any meaning when earlycon is passed is:
>> > > [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
>> > > [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq
>> > >
>> > > and promptly hangs up.
>>
>> I believe that this is a latent FW bug, in a beta FW, exposed by
>> recent
>> changes.
>>
>> I managed to get access to two APM Mustang boards. I can reproduce the
>> issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW.
>> The same kernel boots fine on the other, which has a later released
>> FW.
>>
>> I bisected the issue down to commit:
>>
>> d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain
>> mapping")
>>
>> It seems the beta FW describes the UART interrupt with an Extended
>> Interrupt Descriptor with the Consumer/Producer bit clear. Per the
>> spec,
>> this means "This device produces and consumes this resource", which
>> doesn't make sense here given the UART is not an interrupt controller.
>>
>> The (working) released FW doesn't use an Extended Interrupt Descriptor
>> for this interrupt, sidestepping the issue.
>>
>> Given that (AFAICT) this only affects a known-broken, beta FW, I don't
>> think that we care that much.
>>
>> However, I think there is a larger potential issue here.
>>
>> In acpi_irq_parse_one_cb(), we skip interrupts with an Extended
>> Interrupt Descriptor with the Consumer/Producer bit clear. It sounds
>> like devices which behave as interrupt controllers could legitimately
>> have this bit set for interrupts they generate and deliver to
>> themselves, and we'd erroneously skip these when parsing interrupts.
>>
>> It's not entirely clear to me why this bit exists at all, given that
>> it's not used as part of mapping the interrupt, and if you really want
>> to know you can map the interrupt and look at the result.
>
> It is not entirely clear to anyone (and it has been a source of major
> trouble for other descriptors - ie memory - to the point that it has
> been
> deprecated for *some* descriptors). IIRC (Hanjun ?) the only reason why
> Agustin added the check for that bit in drivers/acpi/resource.c
> (is_gsi()) is to prevent ACPI core code allocating IRQs for the MBIgen
> device that, _erroneously_, was using an extended interrupt descriptor
> to list IRQ lines (that I have no idea what they represent) in order to
> count how many MSI vectors it would have to allocate.
>
> The gist is: removing the check for the extended interrupt descriptor
> producer/consumer bit in ACPI code therefore ignoring that bit should
> be harmless (given that the MBIgen bindings should be changed anyway).
>
> The meaning of that bit (and how we can flag up a FW bug) it is still
> a bit fuzzy IMO.
>
> Agustin, Hanjun, comments ?
>
Yes, that was the reason the check was added, if MBIgen will use a
different mechanism to describe the IRQs it produces we can remove
the check.
I'd still like for the ASWG to get to the bottom of the issue, given
that the resource descriptor and the macro definitions contradict
each other. Hanjun, was this discussed on last week's meeting?
Thanks,
Agustin
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-14 18:47 ` Mark Rutland
2017-03-14 22:06 ` Agustin Vega-Frias
@ 2017-03-22 12:19 ` Lorenzo Pieralisi
2017-03-22 14:06 ` Agustin Vega-Frias
2017-03-22 23:23 ` Hanjun Guo
1 sibling, 2 replies; 23+ messages in thread
From: Lorenzo Pieralisi @ 2017-03-22 12:19 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 14, 2017 at 06:47:34PM +0000, Mark Rutland wrote:
> On Tue, Mar 14, 2017 at 11:49:19AM +0000, Mark Rutland wrote:
> > On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote:
> > > I tried these patches on a m400 (which uses PPIs), and the kernel
> > > fails to come up enough to login via the network (which works with
> > > 4.11rc1 without these patches). So, I suspect there is something
> > > wrong with them.
> >
> > Indeed; sorry about this. I'll see if I can get access to a board to try
> > local debugging.
>
> > > About the only thing it says with any meaning when earlycon is passed is:
> > > [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> > > [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq
> > >
> > > and promptly hangs up.
>
> I believe that this is a latent FW bug, in a beta FW, exposed by recent
> changes.
>
> I managed to get access to two APM Mustang boards. I can reproduce the
> issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW.
> The same kernel boots fine on the other, which has a later released FW.
>
> I bisected the issue down to commit:
>
> d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain mapping")
>
> It seems the beta FW describes the UART interrupt with an Extended
> Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec,
> this means "This device produces and consumes this resource", which
> doesn't make sense here given the UART is not an interrupt controller.
>
> The (working) released FW doesn't use an Extended Interrupt Descriptor
> for this interrupt, sidestepping the issue.
>
> Given that (AFAICT) this only affects a known-broken, beta FW, I don't
> think that we care that much.
>
> However, I think there is a larger potential issue here.
>
> In acpi_irq_parse_one_cb(), we skip interrupts with an Extended
> Interrupt Descriptor with the Consumer/Producer bit clear. It sounds
> like devices which behave as interrupt controllers could legitimately
> have this bit set for interrupts they generate and deliver to
> themselves, and we'd erroneously skip these when parsing interrupts.
>
> It's not entirely clear to me why this bit exists at all, given that
> it's not used as part of mapping the interrupt, and if you really want
> to know you can map the interrupt and look at the result.
It is not entirely clear to anyone (and it has been a source of major
trouble for other descriptors - ie memory - to the point that it has been
deprecated for *some* descriptors). IIRC (Hanjun ?) the only reason why
Agustin added the check for that bit in drivers/acpi/resource.c
(is_gsi()) is to prevent ACPI core code allocating IRQs for the MBIgen
device that, _erroneously_, was using an extended interrupt descriptor
to list IRQ lines (that I have no idea what they represent) in order to
count how many MSI vectors it would have to allocate.
The gist is: removing the check for the extended interrupt descriptor
producer/consumer bit in ACPI code therefore ignoring that bit should
be harmless (given that the MBIgen bindings should be changed anyway).
The meaning of that bit (and how we can flag up a FW bug) it is still
a bit fuzzy IMO.
Agustin, Hanjun, comments ?
Lorenzo
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-20 18:11 ` Ganapatrao Kulkarni
@ 2017-03-22 9:16 ` Ganapatrao Kulkarni
2017-03-22 15:59 ` Mark Rutland
2017-04-03 10:41 ` Ganapatrao Kulkarni
2017-04-11 9:32 ` Hanjun Guo
1 sibling, 2 replies; 23+ messages in thread
From: Ganapatrao Kulkarni @ 2017-03-22 9:16 UTC (permalink / raw)
To: linux-arm-kernel
i am not able to run with latest perf tool, i see issue with memory
corruption in malloc
is this seen from anyone else too?
i am not sure, is this issue with my setup?
root at VAL1-13>perf>> perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1
Performance counter stats for 'sleep 1':
10,815 armv8_pmuv3_0/br_mis_pred/
1.001232167 seconds time elapsed
root at VAL1-13>perf>> ./perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1
*** Error in `./perf': free(): invalid next size (fast): 0x00000000086a7a00 ***
Aborted (core dumped)
root at VAL1-13>perf>> ./perf -v
perf version 4.11.rc3.g093b99
root at VAL1-13>perf>> perf -v
perf version 4.8.rc6.g21c488
root at VAL1-13>perf>> uname -a
Linux VAL1-13 4.11.0-rc2-12139-g3804e12 #1 SMP PREEMPT Wed Mar 22
06:26:28 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
root at VAL1-13>perf>>
On Mon, Mar 20, 2017 at 11:41 PM, Ganapatrao Kulkarni
<gpkulkarni@gmail.com> wrote:
> Hi Hanjun,
>
> On Thu, Mar 16, 2017 at 6:30 PM, Hanjun Guo <guohanjun@huawei.com> wrote:
>> On 2017/3/10 19:04, Mark Rutland wrote:
>>> Hi,
>>>
>>> This series implements ACPI support in the ARM PMU code. It borrows some code
>>> from Jeremy's series [1], but takes a different approach to probing and
>>> association, using the usual hotplug state machine, minimising external changes
>>> required, and simplifying the relationship with the common arm_pmu code.
>>>
>>> The first few patches are preparatory cleanup/refactoring, with the latter half
>>> of the series being specific to ACPI support.
>>>
>>> The series is based on my IRQ rework patches [2]. I've pushed the whole series
>>> out to the arm/perf/acpi branch [3] of my kernel.org repo.
>>>
>>> Due to the innards of the hotplug callback framework, it's not entirely
>>> safe to register a PMU in a hotplug callback. Due to this, we can only
>>> associated hotplugged CPUs with a PMU if a matching CPU was around at
>>> probe time. A similar restriction already applies to DT systems. We may
>>> be able to relax this with some future work.
>>>
>>> I've given this some testing on a Juno platform (using SPIs). To see that IRQs
>>> are correctly associated, I've tested with the following:
>>>
>>> $ taskset -c ${SOME_CPU_HERE} perf record \
>>> -e armv8_pmuv3_0/cpu_cycles/ \
>>> -e armv8_pmuv3_1/cpu_cycles/ \
>>> cat /proc/interrupts
>>>
>>> I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the
>>> association logic. This has also been tested in a VM using PPIs; I do not have
>>> access to a host machine which itself uses PPIs.
>>
>> Booted OK and 'perf list' got on Hisilicon D03:
>>
>> d03-09:~ # perf list
>>
>> List of pre-defined events (to be used in -e):
>>
>> branch-misses [Hardware event]
>> bus-cycles [Hardware event]
>> cache-misses [Hardware event]
>> cache-references [Hardware event]
>> cpu-cycles OR cycles [Hardware event]
>> instructions [Hardware event]
>>
>> alignment-faults [Software event]
>> context-switches OR cs [Software event]
>> cpu-clock [Software event]
>> cpu-migrations OR migrations [Software event]
>> dummy [Software event]
>> emulation-faults [Software event]
>> major-faults [Software event]
>> minor-faults [Software event]
>> page-faults OR faults [Software event]
>> task-clock [Software event]
>>
>> L1-dcache-load-misses [Hardware cache event]
>> L1-dcache-loads [Hardware cache event]
>> L1-dcache-store-misses [Hardware cache event]
>> L1-dcache-stores [Hardware cache event]
>> L1-icache-load-misses [Hardware cache event]
>> L1-icache-loads [Hardware cache event]
>> branch-load-misses [Hardware cache event]
>> branch-loads [Hardware cache event]
>> dTLB-load-misses [Hardware cache event]
>> iTLB-load-misses [Hardware cache event]
>>
>> armv8_pmuv3_0/br_mis_pred/ [Kernel PMU event]
>> armv8_pmuv3_0/br_pred/ [Kernel PMU event]
>> armv8_pmuv3_0/bus_access/ [Kernel PMU event]
>> armv8_pmuv3_0/bus_cycles/ [Kernel PMU event]
>> armv8_pmuv3_0/cid_write_retired/ [Kernel PMU event]
>> armv8_pmuv3_0/cpu_cycles/ [Kernel PMU event]
>> armv8_pmuv3_0/exc_return/ [Kernel PMU event]
>> armv8_pmuv3_0/exc_taken/ [Kernel PMU event]
>> armv8_pmuv3_0/inst_retired/ [Kernel PMU event]
>> armv8_pmuv3_0/inst_spec/ [Kernel PMU event]
>> armv8_pmuv3_0/l1d_cache/ [Kernel PMU event]
>> armv8_pmuv3_0/l1d_cache_refill/ [Kernel PMU event]
>> armv8_pmuv3_0/l1d_cache_wb/ [Kernel PMU event]
>> armv8_pmuv3_0/l1d_tlb_refill/ [Kernel PMU event]
>> armv8_pmuv3_0/l1i_cache/ [Kernel PMU event]
>> armv8_pmuv3_0/l1i_cache_refill/ [Kernel PMU event]
>> armv8_pmuv3_0/l1i_tlb_refill/ [Kernel PMU event]
>> armv8_pmuv3_0/l2d_cache/ [Kernel PMU event]
>> armv8_pmuv3_0/l2d_cache_refill/ [Kernel PMU event]
>> armv8_pmuv3_0/l2d_cache_wb/ [Kernel PMU event]
>> armv8_pmuv3_0/mem_access/ [Kernel PMU event]
>> armv8_pmuv3_0/memory_error/ [Kernel PMU event]
>> armv8_pmuv3_0/sw_incr/ [Kernel PMU event]
>> armv8_pmuv3_0/ttbr_write_retired/ [Kernel PMU event]
>>
>> rNNN [Raw hardware event descriptor]
>> cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor]
>> (see 'man perf-list' on how to encode it)
>>
>> mem:<addr>[/len][:access] [Hardware breakpoint]
>>
>>
>> Try some basic perf event and it works, anything else I can try in specific?
>
> you can try perf fuzzer
>
> thanks
> Ganapat
>
>>
>> Thanks
>> Hanjun
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
thanks
Ganapat
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-16 13:00 ` Hanjun Guo
@ 2017-03-20 18:11 ` Ganapatrao Kulkarni
2017-03-22 9:16 ` Ganapatrao Kulkarni
2017-04-11 9:32 ` Hanjun Guo
0 siblings, 2 replies; 23+ messages in thread
From: Ganapatrao Kulkarni @ 2017-03-20 18:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi Hanjun,
On Thu, Mar 16, 2017 at 6:30 PM, Hanjun Guo <guohanjun@huawei.com> wrote:
> On 2017/3/10 19:04, Mark Rutland wrote:
>> Hi,
>>
>> This series implements ACPI support in the ARM PMU code. It borrows some code
>> from Jeremy's series [1], but takes a different approach to probing and
>> association, using the usual hotplug state machine, minimising external changes
>> required, and simplifying the relationship with the common arm_pmu code.
>>
>> The first few patches are preparatory cleanup/refactoring, with the latter half
>> of the series being specific to ACPI support.
>>
>> The series is based on my IRQ rework patches [2]. I've pushed the whole series
>> out to the arm/perf/acpi branch [3] of my kernel.org repo.
>>
>> Due to the innards of the hotplug callback framework, it's not entirely
>> safe to register a PMU in a hotplug callback. Due to this, we can only
>> associated hotplugged CPUs with a PMU if a matching CPU was around at
>> probe time. A similar restriction already applies to DT systems. We may
>> be able to relax this with some future work.
>>
>> I've given this some testing on a Juno platform (using SPIs). To see that IRQs
>> are correctly associated, I've tested with the following:
>>
>> $ taskset -c ${SOME_CPU_HERE} perf record \
>> -e armv8_pmuv3_0/cpu_cycles/ \
>> -e armv8_pmuv3_1/cpu_cycles/ \
>> cat /proc/interrupts
>>
>> I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the
>> association logic. This has also been tested in a VM using PPIs; I do not have
>> access to a host machine which itself uses PPIs.
>
> Booted OK and 'perf list' got on Hisilicon D03:
>
> d03-09:~ # perf list
>
> List of pre-defined events (to be used in -e):
>
> branch-misses [Hardware event]
> bus-cycles [Hardware event]
> cache-misses [Hardware event]
> cache-references [Hardware event]
> cpu-cycles OR cycles [Hardware event]
> instructions [Hardware event]
>
> alignment-faults [Software event]
> context-switches OR cs [Software event]
> cpu-clock [Software event]
> cpu-migrations OR migrations [Software event]
> dummy [Software event]
> emulation-faults [Software event]
> major-faults [Software event]
> minor-faults [Software event]
> page-faults OR faults [Software event]
> task-clock [Software event]
>
> L1-dcache-load-misses [Hardware cache event]
> L1-dcache-loads [Hardware cache event]
> L1-dcache-store-misses [Hardware cache event]
> L1-dcache-stores [Hardware cache event]
> L1-icache-load-misses [Hardware cache event]
> L1-icache-loads [Hardware cache event]
> branch-load-misses [Hardware cache event]
> branch-loads [Hardware cache event]
> dTLB-load-misses [Hardware cache event]
> iTLB-load-misses [Hardware cache event]
>
> armv8_pmuv3_0/br_mis_pred/ [Kernel PMU event]
> armv8_pmuv3_0/br_pred/ [Kernel PMU event]
> armv8_pmuv3_0/bus_access/ [Kernel PMU event]
> armv8_pmuv3_0/bus_cycles/ [Kernel PMU event]
> armv8_pmuv3_0/cid_write_retired/ [Kernel PMU event]
> armv8_pmuv3_0/cpu_cycles/ [Kernel PMU event]
> armv8_pmuv3_0/exc_return/ [Kernel PMU event]
> armv8_pmuv3_0/exc_taken/ [Kernel PMU event]
> armv8_pmuv3_0/inst_retired/ [Kernel PMU event]
> armv8_pmuv3_0/inst_spec/ [Kernel PMU event]
> armv8_pmuv3_0/l1d_cache/ [Kernel PMU event]
> armv8_pmuv3_0/l1d_cache_refill/ [Kernel PMU event]
> armv8_pmuv3_0/l1d_cache_wb/ [Kernel PMU event]
> armv8_pmuv3_0/l1d_tlb_refill/ [Kernel PMU event]
> armv8_pmuv3_0/l1i_cache/ [Kernel PMU event]
> armv8_pmuv3_0/l1i_cache_refill/ [Kernel PMU event]
> armv8_pmuv3_0/l1i_tlb_refill/ [Kernel PMU event]
> armv8_pmuv3_0/l2d_cache/ [Kernel PMU event]
> armv8_pmuv3_0/l2d_cache_refill/ [Kernel PMU event]
> armv8_pmuv3_0/l2d_cache_wb/ [Kernel PMU event]
> armv8_pmuv3_0/mem_access/ [Kernel PMU event]
> armv8_pmuv3_0/memory_error/ [Kernel PMU event]
> armv8_pmuv3_0/sw_incr/ [Kernel PMU event]
> armv8_pmuv3_0/ttbr_write_retired/ [Kernel PMU event]
>
> rNNN [Raw hardware event descriptor]
> cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor]
> (see 'man perf-list' on how to encode it)
>
> mem:<addr>[/len][:access] [Hardware breakpoint]
>
>
> Try some basic perf event and it works, anything else I can try in specific?
you can try perf fuzzer
thanks
Ganapat
>
> Thanks
> Hanjun
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-10 11:04 Mark Rutland
2017-03-10 22:14 ` Jeremy Linton
@ 2017-03-16 13:00 ` Hanjun Guo
2017-03-20 18:11 ` Ganapatrao Kulkarni
2017-03-24 21:36 ` Jeremy Linton
2 siblings, 1 reply; 23+ messages in thread
From: Hanjun Guo @ 2017-03-16 13:00 UTC (permalink / raw)
To: linux-arm-kernel
On 2017/3/10 19:04, Mark Rutland wrote:
> Hi,
>
> This series implements ACPI support in the ARM PMU code. It borrows some code
> from Jeremy's series [1], but takes a different approach to probing and
> association, using the usual hotplug state machine, minimising external changes
> required, and simplifying the relationship with the common arm_pmu code.
>
> The first few patches are preparatory cleanup/refactoring, with the latter half
> of the series being specific to ACPI support.
>
> The series is based on my IRQ rework patches [2]. I've pushed the whole series
> out to the arm/perf/acpi branch [3] of my kernel.org repo.
>
> Due to the innards of the hotplug callback framework, it's not entirely
> safe to register a PMU in a hotplug callback. Due to this, we can only
> associated hotplugged CPUs with a PMU if a matching CPU was around at
> probe time. A similar restriction already applies to DT systems. We may
> be able to relax this with some future work.
>
> I've given this some testing on a Juno platform (using SPIs). To see that IRQs
> are correctly associated, I've tested with the following:
>
> $ taskset -c ${SOME_CPU_HERE} perf record \
> -e armv8_pmuv3_0/cpu_cycles/ \
> -e armv8_pmuv3_1/cpu_cycles/ \
> cat /proc/interrupts
>
> I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the
> association logic. This has also been tested in a VM using PPIs; I do not have
> access to a host machine which itself uses PPIs.
Booted OK and 'perf list' got on Hisilicon D03:
d03-09:~ # perf list
List of pre-defined events (to be used in -e):
branch-misses [Hardware event]
bus-cycles [Hardware event]
cache-misses [Hardware event]
cache-references [Hardware event]
cpu-cycles OR cycles [Hardware event]
instructions [Hardware event]
alignment-faults [Software event]
context-switches OR cs [Software event]
cpu-clock [Software event]
cpu-migrations OR migrations [Software event]
dummy [Software event]
emulation-faults [Software event]
major-faults [Software event]
minor-faults [Software event]
page-faults OR faults [Software event]
task-clock [Software event]
L1-dcache-load-misses [Hardware cache event]
L1-dcache-loads [Hardware cache event]
L1-dcache-store-misses [Hardware cache event]
L1-dcache-stores [Hardware cache event]
L1-icache-load-misses [Hardware cache event]
L1-icache-loads [Hardware cache event]
branch-load-misses [Hardware cache event]
branch-loads [Hardware cache event]
dTLB-load-misses [Hardware cache event]
iTLB-load-misses [Hardware cache event]
armv8_pmuv3_0/br_mis_pred/ [Kernel PMU event]
armv8_pmuv3_0/br_pred/ [Kernel PMU event]
armv8_pmuv3_0/bus_access/ [Kernel PMU event]
armv8_pmuv3_0/bus_cycles/ [Kernel PMU event]
armv8_pmuv3_0/cid_write_retired/ [Kernel PMU event]
armv8_pmuv3_0/cpu_cycles/ [Kernel PMU event]
armv8_pmuv3_0/exc_return/ [Kernel PMU event]
armv8_pmuv3_0/exc_taken/ [Kernel PMU event]
armv8_pmuv3_0/inst_retired/ [Kernel PMU event]
armv8_pmuv3_0/inst_spec/ [Kernel PMU event]
armv8_pmuv3_0/l1d_cache/ [Kernel PMU event]
armv8_pmuv3_0/l1d_cache_refill/ [Kernel PMU event]
armv8_pmuv3_0/l1d_cache_wb/ [Kernel PMU event]
armv8_pmuv3_0/l1d_tlb_refill/ [Kernel PMU event]
armv8_pmuv3_0/l1i_cache/ [Kernel PMU event]
armv8_pmuv3_0/l1i_cache_refill/ [Kernel PMU event]
armv8_pmuv3_0/l1i_tlb_refill/ [Kernel PMU event]
armv8_pmuv3_0/l2d_cache/ [Kernel PMU event]
armv8_pmuv3_0/l2d_cache_refill/ [Kernel PMU event]
armv8_pmuv3_0/l2d_cache_wb/ [Kernel PMU event]
armv8_pmuv3_0/mem_access/ [Kernel PMU event]
armv8_pmuv3_0/memory_error/ [Kernel PMU event]
armv8_pmuv3_0/sw_incr/ [Kernel PMU event]
armv8_pmuv3_0/ttbr_write_retired/ [Kernel PMU event]
rNNN [Raw hardware event descriptor]
cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor]
(see 'man perf-list' on how to encode it)
mem:<addr>[/len][:access] [Hardware breakpoint]
Try some basic perf event and it works, anything else I can try in specific?
Thanks
Hanjun
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-10 22:14 ` Jeremy Linton
2017-03-14 11:49 ` Mark Rutland
@ 2017-03-15 15:34 ` Mark Rutland
1 sibling, 0 replies; 23+ messages in thread
From: Mark Rutland @ 2017-03-15 15:34 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote:
> On 03/10/2017 05:04 AM, Mark Rutland wrote:
> >I've given this some testing on a Juno platform (using SPIs). To see that IRQs
> >are correctly associated, I've tested with the following:
> >
> > $ taskset -c ${SOME_CPU_HERE} perf record \
> > -e armv8_pmuv3_0/cpu_cycles/ \
> > -e armv8_pmuv3_1/cpu_cycles/ \
> > cat /proc/interrupts
> >
> >I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the
> >association logic. This has also been tested in a VM using PPIs; I do not have
> >access to a host machine which itself uses PPIs.
>
> I tried these patches on a m400 (which uses PPIs), and the kernel
> fails to come up enough to login via the network (which works with
> 4.11rc1 without these patches). So, I suspect there is something
> wrong with them. Although its quite possibly PEBCAK.
It looks like we've gotten to the bottom of the hang in the other
thread; I had a go with a hack to bodge around that (as I have not yet
upgraded the FW).
I had a go with the above taskset pattern (limited to a single PMU) on
an APM Mustang board. Everything seems happy, even when I booted with
maxcpus temporarily capped, where CPUs successfully associated
themselves with the PMU later on.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-14 22:06 ` Agustin Vega-Frias
@ 2017-03-15 2:49 ` Hanjun Guo
0 siblings, 0 replies; 23+ messages in thread
From: Hanjun Guo @ 2017-03-15 2:49 UTC (permalink / raw)
To: linux-arm-kernel
On 2017/3/15 6:06, Agustin Vega-Frias wrote:
> Hi Mark,
>
> On 2017-03-14 14:47, Mark Rutland wrote:
>> On Tue, Mar 14, 2017 at 11:49:19AM +0000, Mark Rutland wrote:
>>> On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote:
>>> > I tried these patches on a m400 (which uses PPIs), and the kernel
>>> > fails to come up enough to login via the network (which works with
>>> > 4.11rc1 without these patches). So, I suspect there is something
>>> > wrong with them.
>>>
>>> Indeed; sorry about this. I'll see if I can get access to a board to try
>>> local debugging.
>>
>>> > About the only thing it says with any meaning when earlycon is
>>> passed is:
>>> > [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing
>>> enabled
>>> > [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq
>>> >
>>> > and promptly hangs up.
>>
>> I believe that this is a latent FW bug, in a beta FW, exposed by recent
>> changes.
>>
>> I managed to get access to two APM Mustang boards. I can reproduce the
>> issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW.
>> The same kernel boots fine on the other, which has a later released FW.
>>
>> I bisected the issue down to commit:
>>
>> d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain
>> mapping")
>>
>> It seems the beta FW describes the UART interrupt with an Extended
>> Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec,
>> this means "This device produces and consumes this resource", which
>> doesn't make sense here given the UART is not an interrupt controller.
>>
>> The (working) released FW doesn't use an Extended Interrupt Descriptor
>> for this interrupt, sidestepping the issue.
>>
>> Given that (AFAICT) this only affects a known-broken, beta FW, I don't
>> think that we care that much.
>>
>> However, I think there is a larger potential issue here.
>>
>> In acpi_irq_parse_one_cb(), we skip interrupts with an Extended
>> Interrupt Descriptor with the Consumer/Producer bit clear. It sounds
>> like devices which behave as interrupt controllers could legitimately
>> have this bit set for interrupts they generate and deliver to
>> themselves, and we'd erroneously skip these when parsing interrupts.
>>
>> It's not entirely clear to me why this bit exists at all, given that
>> it's not used as part of mapping the interrupt, and if you really want
>> to know you can map the interrupt and look at the result.
>>
>
> I think the best approach would be to try to amend the spec and make
> zero mean producer only which is the way it is being treated in Linux.
> That would mean that a device consuming its own interrupts would have to
> have two resources, one for describing the resource as producer and one
> as consumer.
Agreed. I think it's a typo in the spec, should be only produce resource
if it's 0, and that's the behavior in ACPICA core now (both used by
linux kernel and windows).
>
> Unfortunately the spec is vague in some areas like the feature we used
> to implement secondary IRQ controllers which require this patch.
>
> Hanjun, can you bring this up at the next ASWG meeting? I don't normally
> attend but I will ask our ASWG lead to invite me so we can discuss this
> in that forum.
I will do that, and I will send an email to report this issue first with
you and Mark CCed.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-14 18:47 ` Mark Rutland
@ 2017-03-14 22:06 ` Agustin Vega-Frias
2017-03-15 2:49 ` Hanjun Guo
2017-03-22 12:19 ` Lorenzo Pieralisi
1 sibling, 1 reply; 23+ messages in thread
From: Agustin Vega-Frias @ 2017-03-14 22:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mark,
On 2017-03-14 14:47, Mark Rutland wrote:
> On Tue, Mar 14, 2017 at 11:49:19AM +0000, Mark Rutland wrote:
>> On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote:
>> > I tried these patches on a m400 (which uses PPIs), and the kernel
>> > fails to come up enough to login via the network (which works with
>> > 4.11rc1 without these patches). So, I suspect there is something
>> > wrong with them.
>>
>> Indeed; sorry about this. I'll see if I can get access to a board to
>> try
>> local debugging.
>
>> > About the only thing it says with any meaning when earlycon is passed is:
>> > [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
>> > [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq
>> >
>> > and promptly hangs up.
>
> I believe that this is a latent FW bug, in a beta FW, exposed by recent
> changes.
>
> I managed to get access to two APM Mustang boards. I can reproduce the
> issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW.
> The same kernel boots fine on the other, which has a later released FW.
>
> I bisected the issue down to commit:
>
> d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain
> mapping")
>
> It seems the beta FW describes the UART interrupt with an Extended
> Interrupt Descriptor with the Consumer/Producer bit clear. Per the
> spec,
> this means "This device produces and consumes this resource", which
> doesn't make sense here given the UART is not an interrupt controller.
>
> The (working) released FW doesn't use an Extended Interrupt Descriptor
> for this interrupt, sidestepping the issue.
>
> Given that (AFAICT) this only affects a known-broken, beta FW, I don't
> think that we care that much.
>
> However, I think there is a larger potential issue here.
>
> In acpi_irq_parse_one_cb(), we skip interrupts with an Extended
> Interrupt Descriptor with the Consumer/Producer bit clear. It sounds
> like devices which behave as interrupt controllers could legitimately
> have this bit set for interrupts they generate and deliver to
> themselves, and we'd erroneously skip these when parsing interrupts.
>
> It's not entirely clear to me why this bit exists at all, given that
> it's not used as part of mapping the interrupt, and if you really want
> to know you can map the interrupt and look at the result.
>
I think the best approach would be to try to amend the spec and make
zero mean producer only which is the way it is being treated in Linux.
That would mean that a device consuming its own interrupts would have to
have two resources, one for describing the resource as producer and one
as consumer.
Unfortunately the spec is vague in some areas like the feature we used
to implement secondary IRQ controllers which require this patch.
Hanjun, can you bring this up at the next ASWG meeting? I don't normally
attend but I will ask our ASWG lead to invite me so we can discuss this
in that forum.
Thanks,
Agustin
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-14 11:49 ` Mark Rutland
@ 2017-03-14 18:47 ` Mark Rutland
2017-03-14 22:06 ` Agustin Vega-Frias
2017-03-22 12:19 ` Lorenzo Pieralisi
0 siblings, 2 replies; 23+ messages in thread
From: Mark Rutland @ 2017-03-14 18:47 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 14, 2017 at 11:49:19AM +0000, Mark Rutland wrote:
> On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote:
> > I tried these patches on a m400 (which uses PPIs), and the kernel
> > fails to come up enough to login via the network (which works with
> > 4.11rc1 without these patches). So, I suspect there is something
> > wrong with them.
>
> Indeed; sorry about this. I'll see if I can get access to a board to try
> local debugging.
> > About the only thing it says with any meaning when earlycon is passed is:
> > [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> > [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq
> >
> > and promptly hangs up.
I believe that this is a latent FW bug, in a beta FW, exposed by recent
changes.
I managed to get access to two APM Mustang boards. I can reproduce the
issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW.
The same kernel boots fine on the other, which has a later released FW.
I bisected the issue down to commit:
d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain mapping")
It seems the beta FW describes the UART interrupt with an Extended
Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec,
this means "This device produces and consumes this resource", which
doesn't make sense here given the UART is not an interrupt controller.
The (working) released FW doesn't use an Extended Interrupt Descriptor
for this interrupt, sidestepping the issue.
Given that (AFAICT) this only affects a known-broken, beta FW, I don't
think that we care that much.
However, I think there is a larger potential issue here.
In acpi_irq_parse_one_cb(), we skip interrupts with an Extended
Interrupt Descriptor with the Consumer/Producer bit clear. It sounds
like devices which behave as interrupt controllers could legitimately
have this bit set for interrupts they generate and deliver to
themselves, and we'd erroneously skip these when parsing interrupts.
It's not entirely clear to me why this bit exists at all, given that
it's not used as part of mapping the interrupt, and if you really want
to know you can map the interrupt and look at the result.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-10 22:14 ` Jeremy Linton
@ 2017-03-14 11:49 ` Mark Rutland
2017-03-14 18:47 ` Mark Rutland
2017-03-15 15:34 ` Mark Rutland
1 sibling, 1 reply; 23+ messages in thread
From: Mark Rutland @ 2017-03-14 11:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote:
> On 03/10/2017 05:04 AM, Mark Rutland wrote:
> >This series implements ACPI support in the ARM PMU code.
> I tried these patches on a m400 (which uses PPIs), and the kernel
> fails to come up enough to login via the network (which works with
> 4.11rc1 without these patches). So, I suspect there is something
> wrong with them.
Indeed; sorry about this. I'll see if I can get access to a board to try
local debugging.
I assume that these have successfully booted with the other ACPI PMU
patches?
> Given that SPCR/etc is also broken and the kernel itself seems to
> fail if I give it a full earlycon line, I can't pin down whats going
> on with the PMU code until I fix the console.
If there are known broken tables, it's possible that the MADT GICC is
also broken, and we're registering/unregistering an erroneously
described interrupt.
> About the only thing it says with any meaning when earlycon is passed is:
> [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq
>
> and promptly hangs up.
I guess that's at the point it transfers over to the real console
driver. If you're not already doing so, also passing "keep_bootcon" may
get more output.
> I'm OOO for the next week, and will debug this further when I return
> if no one else makes any progress.
I'll see what I can do until then.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
2017-03-10 11:04 Mark Rutland
@ 2017-03-10 22:14 ` Jeremy Linton
2017-03-14 11:49 ` Mark Rutland
2017-03-15 15:34 ` Mark Rutland
2017-03-16 13:00 ` Hanjun Guo
2017-03-24 21:36 ` Jeremy Linton
2 siblings, 2 replies; 23+ messages in thread
From: Jeremy Linton @ 2017-03-10 22:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 03/10/2017 05:04 AM, Mark Rutland wrote:
> Hi,
>
> This series implements ACPI support in the ARM PMU code. It borrows some code
> from Jeremy's series [1], but takes a different approach to probing and
> association, using the usual hotplug state machine, minimising external changes
> required, and simplifying the relationship with the common arm_pmu code.
>
> The first few patches are preparatory cleanup/refactoring, with the latter half
> of the series being specific to ACPI support.
>
> The series is based on my IRQ rework patches [2]. I've pushed the whole series
> out to the arm/perf/acpi branch [3] of my kernel.org repo.
>
> Due to the innards of the hotplug callback framework, it's not entirely
> safe to register a PMU in a hotplug callback. Due to this, we can only
> associated hotplugged CPUs with a PMU if a matching CPU was around at
> probe time. A similar restriction already applies to DT systems. We may
> be able to relax this with some future work.
Which is disappointing, as I thought that was one of Lorenzo's
complaints about the last patch series.
>
> I've given this some testing on a Juno platform (using SPIs). To see that IRQs
> are correctly associated, I've tested with the following:
>
> $ taskset -c ${SOME_CPU_HERE} perf record \
> -e armv8_pmuv3_0/cpu_cycles/ \
> -e armv8_pmuv3_1/cpu_cycles/ \
> cat /proc/interrupts
>
> I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the
> association logic. This has also been tested in a VM using PPIs; I do not have
> access to a host machine which itself uses PPIs.
I tried these patches on a m400 (which uses PPIs), and the kernel fails
to come up enough to login via the network (which works with 4.11rc1
without these patches). So, I suspect there is something wrong with
them. Although its quite possibly PEBCAK.
Given that SPCR/etc is also broken and the kernel itself seems to fail
if I give it a full earlycon line, I can't pin down whats going on with
the PMU code until I fix the console.
About the only thing it says with any meaning when earlycon is passed is:
[ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq
and promptly hangs up.
I'm OOO for the next week, and will debug this further when I return if
no one else makes any progress.
>
> Thanks,
> Mark.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/482397.html
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492891.html
> [3] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm/perf/acpi
>
> Mark Rutland (14):
> drivers/perf: arm_pmu: remove pointless PMU disabling
> drivers/perf: arm_pmu: define armpmu_init_fn
> drivers/perf: arm_pmu: fold init into alloc
> drivers/perf: arm_pmu: factor out pmu registration
> drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs()
> drivers/perf: arm_pmu: handle no platform_device
> drivers/perf: arm_pmu: rename irq request/free functions
> drivers/perf: arm_pmu: split cpu-local irq request/free
> drivers/perf: arm_pmu: move irq request/free into probe
> drivers/perf: arm_pmu: split out platform device probe logic
> arm64: add function to get a cpu's MADT GICC table
> arm64: kill acpi_set_mailbox_entry()
> drivers/perf: arm_pmu: add ACPI framework
> arm64: pmuv3: use arm_pmu ACPI framework
>
> arch/arm64/include/asm/acpi.h | 7 +-
> arch/arm64/kernel/acpi_parking_protocol.c | 38 +--
> arch/arm64/kernel/perf_event.c | 26 +-
> arch/arm64/kernel/smp.c | 19 +-
> drivers/perf/Kconfig | 4 +
> drivers/perf/Makefile | 3 +-
> drivers/perf/arm_pmu.c | 383 ++++++++----------------------
> drivers/perf/arm_pmu_acpi.c | 237 ++++++++++++++++++
> drivers/perf/arm_pmu_platform.c | 235 ++++++++++++++++++
> include/linux/cpuhotplug.h | 1 +
> include/linux/perf/arm_pmu.h | 22 +-
> 11 files changed, 626 insertions(+), 349 deletions(-)
> create mode 100644 drivers/perf/arm_pmu_acpi.c
> create mode 100644 drivers/perf/arm_pmu_platform.c
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
@ 2017-03-10 11:04 Mark Rutland
2017-03-10 22:14 ` Jeremy Linton
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Mark Rutland @ 2017-03-10 11:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series implements ACPI support in the ARM PMU code. It borrows some code
from Jeremy's series [1], but takes a different approach to probing and
association, using the usual hotplug state machine, minimising external changes
required, and simplifying the relationship with the common arm_pmu code.
The first few patches are preparatory cleanup/refactoring, with the latter half
of the series being specific to ACPI support.
The series is based on my IRQ rework patches [2]. I've pushed the whole series
out to the arm/perf/acpi branch [3] of my kernel.org repo.
Due to the innards of the hotplug callback framework, it's not entirely
safe to register a PMU in a hotplug callback. Due to this, we can only
associated hotplugged CPUs with a PMU if a matching CPU was around at
probe time. A similar restriction already applies to DT systems. We may
be able to relax this with some future work.
I've given this some testing on a Juno platform (using SPIs). To see that IRQs
are correctly associated, I've tested with the following:
$ taskset -c ${SOME_CPU_HERE} perf record \
-e armv8_pmuv3_0/cpu_cycles/ \
-e armv8_pmuv3_1/cpu_cycles/ \
cat /proc/interrupts
I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the
association logic. This has also been tested in a VM using PPIs; I do not have
access to a host machine which itself uses PPIs.
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/482397.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492891.html
[3] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm/perf/acpi
Mark Rutland (14):
drivers/perf: arm_pmu: remove pointless PMU disabling
drivers/perf: arm_pmu: define armpmu_init_fn
drivers/perf: arm_pmu: fold init into alloc
drivers/perf: arm_pmu: factor out pmu registration
drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs()
drivers/perf: arm_pmu: handle no platform_device
drivers/perf: arm_pmu: rename irq request/free functions
drivers/perf: arm_pmu: split cpu-local irq request/free
drivers/perf: arm_pmu: move irq request/free into probe
drivers/perf: arm_pmu: split out platform device probe logic
arm64: add function to get a cpu's MADT GICC table
arm64: kill acpi_set_mailbox_entry()
drivers/perf: arm_pmu: add ACPI framework
arm64: pmuv3: use arm_pmu ACPI framework
arch/arm64/include/asm/acpi.h | 7 +-
arch/arm64/kernel/acpi_parking_protocol.c | 38 +--
arch/arm64/kernel/perf_event.c | 26 +-
arch/arm64/kernel/smp.c | 19 +-
drivers/perf/Kconfig | 4 +
drivers/perf/Makefile | 3 +-
drivers/perf/arm_pmu.c | 383 ++++++++----------------------
drivers/perf/arm_pmu_acpi.c | 237 ++++++++++++++++++
drivers/perf/arm_pmu_platform.c | 235 ++++++++++++++++++
include/linux/cpuhotplug.h | 1 +
include/linux/perf/arm_pmu.h | 22 +-
11 files changed, 626 insertions(+), 349 deletions(-)
create mode 100644 drivers/perf/arm_pmu_acpi.c
create mode 100644 drivers/perf/arm_pmu_platform.c
--
1.9.1
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2017-04-11 9:32 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-17 2:11 [PATCH 00/14] arm_pmu: ACPI support Itaru Kitayama
2017-03-23 10:54 ` Mark Rutland
2017-03-25 3:18 ` Itaru Kitayama
-- strict thread matches above, loose matches on Subject: below --
2017-03-10 11:04 Mark Rutland
2017-03-10 22:14 ` Jeremy Linton
2017-03-14 11:49 ` Mark Rutland
2017-03-14 18:47 ` Mark Rutland
2017-03-14 22:06 ` Agustin Vega-Frias
2017-03-15 2:49 ` Hanjun Guo
2017-03-22 12:19 ` Lorenzo Pieralisi
2017-03-22 14:06 ` Agustin Vega-Frias
2017-03-22 23:23 ` Hanjun Guo
2017-03-15 15:34 ` Mark Rutland
2017-03-16 13:00 ` Hanjun Guo
2017-03-20 18:11 ` Ganapatrao Kulkarni
2017-03-22 9:16 ` Ganapatrao Kulkarni
2017-03-22 15:59 ` Mark Rutland
2017-04-03 10:41 ` Ganapatrao Kulkarni
2017-04-03 11:12 ` Mark Rutland
2017-04-11 9:32 ` Hanjun Guo
2017-03-24 21:36 ` Jeremy Linton
2017-03-28 11:31 ` Mark Rutland
2017-03-28 14:41 ` Jeremy Linton
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.