With a perf user tool compiled from a 3.5rc1+ kernel I cannot
use the 'p' attribute anymore. Always get
ak@petrock:~> ./perf record -e cycles:p ./t
Error: sys_perf_event_open() syscall returned with 22 (Invalid argument). /bin/dmesg may provide additional information.
Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
./t: Terminated
With an older perf it works, so the kernel is ok.
ak@petrock:~> ./perf record -e cycles:p ./t
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.005 MB perf.data (~217 samples) ]
ak@petrock:~>
-Andi
--
[email protected] -- Speaking for myself only.
What CPU model?
On Thu, Jun 7, 2012 at 10:23 PM, Andi Kleen <[email protected]> wrote:
>
> With a perf user tool compiled from a 3.5rc1+ kernel I cannot
> use the 'p' attribute anymore. Always get
>
> ak@petrock:~> ./perf record -e cycles:p ./t
>
> Error: sys_perf_event_open() syscall returned with 22 (Invalid argument). /bin/dmesg may provide additional information.
>
> Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
>
> ./t: Terminated
>
> With an older perf it works, so the kernel is ok.
>
> ak@petrock:~> ./perf record -e cycles:p ./t
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.005 MB perf.data (~217 samples) ]
> ak@petrock:~>
>
>
> -Andi
> --
> [email protected] -- Speaking for myself only.
On Thu, Jun 07, 2012 at 10:25:47PM +0200, Stephane Eranian wrote:
> What CPU model?
I see it on Sandy Bridge and others. But the perf tool shouldn't know anything
about that anyways? The kernel driver is ok
-Andi
On Thu, Jun 07, 2012 at 10:25:47PM +0200, Stephane Eranian wrote:
> What CPU model?
+1, latest tip works for me ;)
jirka
>
> On Thu, Jun 7, 2012 at 10:23 PM, Andi Kleen <[email protected]> wrote:
> >
> > With a perf user tool compiled from a 3.5rc1+ kernel I cannot
> > use the 'p' attribute anymore. Always get
> >
> > ak@petrock:~> ./perf record -e cycles:p ./t
> >
> > ?Error: sys_perf_event_open() syscall returned with 22 (Invalid argument). ?/bin/dmesg may provide additional information.
> >
> > ?Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
> >
> > ./t: Terminated
> >
> > With an older perf it works, so the kernel is ok.
> >
> > ak@petrock:~> ./perf record -e cycles:p ./t
> > [ perf record: Woken up 1 times to write data ]
> > [ perf record: Captured and wrote 0.005 MB perf.data (~217 samples) ]
> > ak@petrock:~>
> >
> >
> > -Andi
> > --
> > [email protected] -- Speaking for myself only.
On Thu, Jun 7, 2012 at 10:23 PM, Andi Kleen <[email protected]> wrote:
>
> With a perf user tool compiled from a 3.5rc1+ kernel I cannot
> use the 'p' attribute anymore. Always get
>
> ak@petrock:~> ./perf record -e cycles:p ./t
>
> Error: sys_perf_event_open() syscall returned with 22 (Invalid argument). /bin/dmesg may provide additional information.
>
> Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
>
Remember that PEBS is disabled on SNB unless you have the new ucode + my patch.
> ./t: Terminated
>
> With an older perf it works, so the kernel is ok.
>
> ak@petrock:~> ./perf record -e cycles:p ./t
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.005 MB perf.data (~217 samples) ]
> ak@petrock:~>
>
>
> -Andi
> --
> [email protected] -- Speaking for myself only.
On Thu, Jun 07, 2012 at 10:49:15PM +0200, Jiri Olsa wrote:
> On Thu, Jun 07, 2012 at 10:25:47PM +0200, Stephane Eranian wrote:
> > What CPU model?
> +1, latest tip works for me ;)
how about mainline?
-Andi
On Thu, Jun 07, 2012 at 10:53:19PM +0200, Stephane Eranian wrote:
> On Thu, Jun 7, 2012 at 10:23 PM, Andi Kleen <[email protected]> wrote:
> >
> > With a perf user tool compiled from a 3.5rc1+ kernel I cannot
> > use the 'p' attribute anymore. Always get
> >
> > ak@petrock:~> ./perf record -e cycles:p ./t
> >
> > ?Error: sys_perf_event_open() syscall returned with 22 (Invalid argument). ?/bin/dmesg may provide additional information.
> >
> > ?Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
> >
> Remember that PEBS is disabled on SNB unless you have the new ucode + my patch.
This is not the problem. This was actually a -E where it was not disabled
in my tree. And the older perf binary works, so it's clearly not a kernel
problem.
-Andi
On Thu, Jun 07, 2012 at 10:57:22PM +0200, Andi Kleen wrote:
> On Thu, Jun 07, 2012 at 10:49:15PM +0200, Jiri Olsa wrote:
> > On Thu, Jun 07, 2012 at 10:25:47PM +0200, Stephane Eranian wrote:
> > > What CPU model?
> > +1, latest tip works for me ;)
>
> how about mainline?
>
> -Andi
yes..
jirka
---
[jolsa@dhcp-26-214 perf]$ ./perf record -e cycles:p date
Thu Jun 7 23:33:02 CEST 2012
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.006 MB perf.data (~260 samples) ]
[jolsa@dhcp-26-214 perf]$ git show
commit 513335f964a17bd99a699b939391eb111aa5f65b
Merge: 0c30989 4c01acc
Author: Linus Torvalds <[email protected]>
Date: Thu Jun 7 09:06:54 2012 -0700
Em Thu, Jun 07, 2012 at 10:58:36PM +0200, Andi Kleen escreveu:
> On Thu, Jun 07, 2012 at 10:53:19PM +0200, Stephane Eranian wrote:
> > On Thu, Jun 7, 2012 at 10:23 PM, Andi Kleen <[email protected]> wrote:
> > >
> > > With a perf user tool compiled from a 3.5rc1+ kernel I cannot
> > > use the 'p' attribute anymore. Always get
> > >
> > > ak@petrock:~> ./perf record -e cycles:p ./t
> > >
> > > ?Error: sys_perf_event_open() syscall returned with 22 (Invalid argument). ?/bin/dmesg may provide additional information.
> > >
> > > ?Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
> > >
> > Remember that PEBS is disabled on SNB unless you have the new ucode + my patch.
>
> This is not the problem. This was actually a -E where it was not disabled
> in my tree. And the older perf binary works, so it's clearly not a kernel
> problem.
Are you sure the old one works? Perhaps it silently falls back to
cpu-clock?
What 'perf evlist -v' says?
- Arnaldo
On Thu, Jun 7, 2012 at 10:58 PM, Andi Kleen <[email protected]> wrote:
> On Thu, Jun 07, 2012 at 10:53:19PM +0200, Stephane Eranian wrote:
>> On Thu, Jun 7, 2012 at 10:23 PM, Andi Kleen <[email protected]> wrote:
>> >
>> > With a perf user tool compiled from a 3.5rc1+ kernel I cannot
>> > use the 'p' attribute anymore. Always get
>> >
>> > ak@petrock:~> ./perf record -e cycles:p ./t
>> >
>> > Error: sys_perf_event_open() syscall returned with 22 (Invalid argument). /bin/dmesg may provide additional information.
>> >
>> > Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
>> >
>> Remember that PEBS is disabled on SNB unless you have the new ucode + my patch.
>
> This is not the problem. This was actually a -E where it was not disabled
> in my tree. And the older perf binary works, so it's clearly not a kernel
> problem.
What's -E?
>
> -Andi
> Are you sure the old one works? Perhaps it silently falls back to
> cpu-clock?
Yes i'm sure. I was actually debugging some kernel pebs code,
and had a heavily instrumented pebs code path and was first trying
to figure out what went wrong in the kernel, until I realized
that the userland was broken.
Does :p work for anyone else?
BTW I hope the perf userland becomes more stable again. Recently I've had
far more trouble with the user binary than the kernel driver, which
is unusal.
-Andi
--
[email protected] -- Speaking for myself only.
Em Fri, Jun 08, 2012 at 05:10:09AM +0200, Andi Kleen escreveu:
> > Are you sure the old one works? Perhaps it silently falls back to
> > cpu-clock?
> Yes i'm sure. I was actually debugging some kernel pebs code,
> and had a heavily instrumented pebs code path and was first trying
> to figure out what went wrong in the kernel, until I realized
> that the userland was broken.
>
> Does :p work for anyone else?
It seems to work for Linus on Ivy Bridge with what is on tip/perf/urgent
> BTW I hope the perf userland becomes more stable again. Recently I've had
> far more trouble with the user binary than the kernel driver, which
> is unusal.
Well, as a feedback your post is very much appreciated, we'll try to do
better.
What areas do you feel are more troubling? Anything you reported that
still hasn't been fixed?
Probably we should stop working on features and just process patches and
work on a suite of autotest scripts, something we've been discussing but
not working that much at.
- Arnaldo
On Fri, Jun 08, 2012 at 12:48:14PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 08, 2012 at 05:10:09AM +0200, Andi Kleen escreveu:
> > > Are you sure the old one works? Perhaps it silently falls back to
> > > cpu-clock?
>
> > Yes i'm sure. I was actually debugging some kernel pebs code,
> > and had a heavily instrumented pebs code path and was first trying
> > to figure out what went wrong in the kernel, until I realized
> > that the userland was broken.
> >
> > Does :p work for anyone else?
>
> It seems to work for Linus on Ivy Bridge with what is on tip/perf/urgent
Hmm, maybe some local problem. I'll do some debugging and a bisect.
-Andi
Hmm, the problem disappeared after a make clean.
Sorry for the noise.
-Andi
Em Fri, Jun 08, 2012 at 11:55:49PM +0200, Andi Kleen escreveu:
> Hmm, the problem disappeared after a make clean.
> Sorry for the noise.
Thanks for the feedback!
- Arnaldo