[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZByRqNRX10knmnuo@FVFF77S0Q05N.cambridge.arm.com>
Date: Thu, 23 Mar 2023 17:51:36 +0000
From: Mark Rutland <mark.rutland@....com>
To: wangxiaolei <xiaolei.wang@...driver.com>
Cc: will@...nel.org, peterz@...radead.org, mingo@...hat.com,
acme@...nel.org, alexander.shishkin@...ux.intel.com,
jolsa@...nel.org, namhyung@...nel.org, irogers@...gle.com,
linux@...linux.org.uk, linux-arm-kernel@...ts.infradead.org,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: perf record -e branch-misses ls > /dev/null
On Wed, Mar 08, 2023 at 03:56:41PM +0800, wangxiaolei wrote:
> hi
>
> When I use the perf tool on nxp-imx6sx, the CPU is armv7 cortex-A9 to test,
> I execute the perf record -e branch-misses ls > /dev/null command, but the
> perf report result is indeed:
> perf report
> Error:
> The perf.data data has no samples!
> # To display the perf.data header info, please use --header/--header-only
> options.
Which kernel version are you seeing this with?
Is anything printed regarding the PMU in dmesg?
> root@...-imx6:~# perf list hardware
>
> List of pre-defined events (to be used in -e):
>
> branch-instructions OR branches [Hardware event]
> 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]
That's just listing the generic HW events; does the PMU actually show up under
sysfs?
What do you see if you run:
$ ls /sys/bus/event_source/devices/
> And not only this one hardware event, only cycles are working normally in
> the following supported hardware time, other hardware events are not
> interrupted and reported
Can you explain what you mean by "not interrupted and reported"?
Do you mean the PMU interrupt isn't firing?
> , and the value in the read PMXEVCNTR register is
> always -1, and the PMCR register E, bit[0 ] it will be written to 0 before
> reading the PMXEVCNTR register.
How are you reading PMXEVCNTR?
Have you instrumented the PMU driver, or are you using other code?
> I don’t know if the value in the PMXEVCNTR register is always -1 for this
> reason. Does anyone have any good suggestions for debugging this problem?
There are a number of potential reasons for this; if you can answer some of my
questions above it'd help to narrow this down.
Thanks,
Mark.
Powered by blists - more mailing lists