Problem solved. Test was wrong. Was using >= instead of >. It hit this event only because it had exactly 8 umasks!
Thanks for reporting and tracking down the problem. Please pull again. On Wed, Aug 29, 2012 at 5:32 PM, stephane eranian <eran...@googlemail.com> wrote: > On Wed, Aug 29, 2012 at 5:02 PM, William Cohen <wco...@redhat.com> wrote: >> On 08/29/2012 06:28 AM, stephane eranian wrote: >>> On Tue, Aug 28, 2012 at 4:45 PM, William Cohen <wco...@redhat.com> wrote: >> >>>> Hi Stephane, >>>> >>>> Thanks so much for the fresh libpfm-4.3.0 release. I just built a version >>>> for fedora rawhide at: >>>> >>>> http://koji.fedoraproject.org/koji/buildinfo?buildID=350950 >>>> >>>> I ran ./libpfm-4.3.0/tests/validate on a fedora 17 Intel Ivy bridge and >>>> AMD family 10H machine. The tests all listed as pass with the exception of >>>> the following for Intel Ivy Bridge: >>>> >>>> checking perf (120 events): pmu: perf event80: sunrpc :: numasks >>>> too big (<8) >>>> Failed >>>> >>>> And the following for AMD family 10H: >>>> >>>> checking perf (119 events): pmu: perf event85: sunrpc :: numasks >>>> too big (<8) >>>> Failed >>>> >>> Weird, because I don't see that running on my Ubuntu distro. >>> The sunrpc word looks suspicous to me. I don't think there is an event >>> or umask with that name. >> >> Hi Stephane, >> >> libpfm is using the enumeration for perf to find out which events are >> avilable on the machine. It looks like the first tracepoint event listed >> from "perf list" is" >> >> sunrpc:rpc_call_status [Tracepoint event] >> >> Are the fields for sunrpc correct? >> >> (gdb) print perf_pe[80] >> $10 = {name = 0x6aa4a0 "sunrpc", desc = 0x41a519 "tracepoint", equiv = 0x0, >> id = 0, modmsk = 0, type = 2, numasks = 8, ngrp = 1, >> umask_ovfl_idx = 18446744073709551615, umasks = {{ >> uname = 0x6aa4c0 "rpc_call_status", udesc = 0x6aa4c0 "rpc_call_status", >> uid = 1037, uflags = 0, grpid = 0}, {uname = 0x6aa4e0 >> "rpc_bind_status", >> udesc = 0x6aa4e0 "rpc_bind_status", uid = 1036, uflags = 0, grpid = >> 0}, { >> uname = 0x6aa500 "rpc_connect_status", >> udesc = 0x6aa500 "rpc_connect_status", uid = 1035, uflags = 0, >> grpid = 0}, {uname = 0x6aa520 "rpc_task_begin", >> udesc = 0x6aa520 "rpc_task_begin", uid = 1034, uflags = 0, grpid = 0}, >> { >> uname = 0x6aa540 "rpc_task_run_action", >> udesc = 0x6aa540 "rpc_task_run_action", uid = 1033, uflags = 0, >> grpid = 0}, {uname = 0x6aa560 "rpc_task_complete", >> udesc = 0x6aa560 "rpc_task_complete", uid = 1032, uflags = 0, >> grpid = 0}, {uname = 0x6aa580 "rpc_task_sleep", >> udesc = 0x6aa580 "rpc_task_sleep", uid = 1031, uflags = 0, grpid = 0}, >> { >> uname = 0x6aa5a0 "rpc_task_wakeup", udesc = 0x6aa5a0 "rpc_task_wakeup", >> uid = 1030, uflags = 0, grpid = 0}}} >> >> It looks like perf_pe[80].umask_ovfl_idx should be 0 like the later entries. >> > Ok, I know what I did not catch that. > You need to run as root to be able to parse /sys/kernel/debug > AND you need to have the sunrpc code builtin or module loaded. > I had neither of those two. Let me fix this. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
