lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ