* Recent review of SystemTap test results on ARM running Fedora 15 hard float.
@ 2012-02-23 19:06 William Cohen
2012-02-23 20:55 ` David Smith
0 siblings, 1 reply; 14+ messages in thread
From: William Cohen @ 2012-02-23 19:06 UTC (permalink / raw)
To: systemtap
I reviewed the SystemTap testsuite failures for Fedora 15 hard float running on ARM. You can see the recent ARM test results in dejazilla at:
http://web.elastic.org/~dejazilla/viewsummary.php?_offset=0&_limit=40&_sort=1A&summary=&age=&rg=&tool=&variant=%3D%27armv7l-unknown-linux-gnu%27&versions=&pass=&fail=&kpass=&kfail=&xpass=&xfail=&untested=&unresolved=&unsupported=&warning=&error=
FAIL: backtrace-unwindsyms (0 0)
FAIL: bz6503 0 0
bz6503.exp fails because no jffs2 or ext2 kernel modules.
Maybe use nfs and fat instead?
FAIL: cmd_parse15: eof
cmd_parse.exp fail because avahi problems
FAIL: global_end (11)
global_end.exp fails because "time = 0" is output by global_end2.stp
FAIL: gtod (0)
gettimeofday_*() function do not work properly on arm
FAIL: ipaddr_IPv4_recvmsg find 'nc'
doesn't seem to find /usr/bin/nc, but nc rpm has been installed on machine
FAIL: OVERLOAD2 no expected error
Looks like this is caused by arm always returning 0 for get_cycles().
This failure is troubling because OVERLOAD stuff will not work.
FAIL: prcwildcard function
failed because no user space probing is available
FAIL: systemtap.base/pt_user_mode.stp startup (eof)
FAIL: systemtap.examples/profiling/thread-times run
failed because on startup unable to register probe:
perf.type(1).config(0).sample(1000000)
FAIL: vma_vdsodefault
vma_vdso.stp uses uaddr() which didn't work on arm.
FAIL: warnings (timeout)
FAIL: warnings (0)
took too long to compile systemtap.base/warning.stp, about 2:30
fixed in commit 9e6bcc7a2ee69f4211135900e99bad9e1abfc665
FAIL: int64 function arguments -- numeric
FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf
PR13466
FAIL: systemtap.examples/io/mbrwatch run
ran test as normal user dd used to test this fails as a result
FAIL: systemtap.examples/memory/hw_watch_addr run
FAIL: systemtap.examples/memory/hw_watch_sym run
not enough hardware breakpoints available:
WARNING: Too many hardware breakpoint probes requested for arm (1 vs. 0)
`
FAIL: uprobeslibgcc-O3default-prelink-debug prelink ./libuprobeslibgcc-O3default-prelink-debug.so
FAIL: uprobeslibgcc-O3default-prelink-sep-debug prelink ./libuprobeslibgcc-O3default-prelink-sep-debug.so
FAIL: uprobeslibgcc-O3default-prelink-sep-debug-after prelink ./libuprobeslibgcc-O3default-prelink-sep-debug-after.so
uprobes not available on arm
FAIL: buildok/eighteen.stp
unable to find kernel.function("*audit_getname@kernel/auditsc.c")
CONFIG_AUDITSYSCALL is not enabled on arm fedora 15 kernels,
something is diabling.
FAIL: buildok/process_test.stp
unable to find $signr for:
tapset/signal.stp:606:15
:607:33
FAIL: buildok/syscalls-arch-detailed.stp
unable to probe syscall.sigaltstack.return
ARM doesn't have a sys_sigaltstack() function in the kernel.
FAIL: buildok/tcp-all-probes.stp
FAIL: buildok/tcp-detailed.stp
unable to get identifier '$optname' tapset/tcp.stp:369:27
FAIL: buildok/twentyeightprime.stp
CONFIG_UTRACE not available (seems like that should be UNTESTED)
FAIL: semok/thirtynine.stp
can't access identifier '$prev' at .../semok/thirtynine.stp:6:40
FAIL: semok/thirtysix.stp
WARNING: Can't parse SDT_V3 operand 'r0': identifier '$arg1' at /media/greatpla\
ins/wcohen/systemtap_write/systemtap/testsuite/semok/thirtysix.stp:11:53
FAIL: systemtap.stress/current.stp compilation
can't probe kernel.function("__switch_to").call
need to adapt for arm
FAIL: 32-bit * nd_syscall
ARM registers.stp can only read the first 4 arguments in registers.
fifth/sixth arguments are problems on ARM, so these tests fail.
FAIL: unprivileged embedded C: no embedded C: --unprivileged: inet_get_ip_source(long)
FAIL: unprivileged embedded C: no embedded C: --unprivileged: get_ip(long)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-23 19:06 Recent review of SystemTap test results on ARM running Fedora 15 hard float William Cohen
@ 2012-02-23 20:55 ` David Smith
2012-02-23 22:06 ` William Cohen
2012-02-23 22:12 ` David Smith
0 siblings, 2 replies; 14+ messages in thread
From: David Smith @ 2012-02-23 20:55 UTC (permalink / raw)
To: William Cohen; +Cc: systemtap
On 02/23/2012 01:06 PM, William Cohen wrote:
> I reviewed the SystemTap testsuite failures for Fedora 15 hard float running on ARM. You can see the recent ARM test results in dejazilla at:
>
> http://web.elastic.org/~dejazilla/viewsummary.php?_offset=0&_limit=40&_sort=1A&summary=&age=&rg=&tool=&variant=%3D%27armv7l-unknown-linux-gnu%27&versions=&pass=&fail=&kpass=&kfail=&xpass=&xfail=&untested=&unresolved=&unsupported=&warning=&error=
Here are some notes on certain tests:
> FAIL: ipaddr_IPv4_recvmsg find 'nc'
> doesn't seem to find /usr/bin/nc, but nc rpm has been installed on machine
That's odd. That test tries to find nc by running "which nc". If that
succeeds, it assumes nc is there. Does "which nc" find /usr/bin/nc and
return a 0 exit code?
> FAIL: vma_vdsodefault
> vma_vdso.stp uses uaddr() which didn't work on arm.
Hmm, can you tell in systemtap.log what part of 'uaddr()' didn't work?
>
> FAIL: uprobeslibgcc-O3default-prelink-debug prelink ./libuprobeslibgcc-O3default-prelink-debug.so
> FAIL: uprobeslibgcc-O3default-prelink-sep-debug prelink ./libuprobeslibgcc-O3default-prelink-sep-debug.so
> FAIL: uprobeslibgcc-O3default-prelink-sep-debug-after prelink ./libuprobeslibgcc-O3default-prelink-sep-debug-after.so
> uprobes not available on arm
This is odd. I would have thought the testsuite would have realized
this platform didn't have uprobes, and not run the test at all. Which
.exp is this, exelib.exp?
> FAIL: buildok/syscalls-arch-detailed.stp
> unable to probe syscall.sigaltstack.return
> ARM doesn't have a sys_sigaltstack() function in the kernel.
That's PR13480.
> FAIL: buildok/tcp-all-probes.stp
> FAIL: buildok/tcp-detailed.stp
> unable to get identifier '$optname' tapset/tcp.stp:369:27
Hmm, this one looks like a debuginfo problem. Could you show me the
output of:
# stap -L 'kernel.function("tcp_setsockopt")
> FAIL: buildok/twentyeightprime.stp
> CONFIG_UTRACE not available (seems like that should be UNTESTED)
Actually it should be KFAIL. I'll fix this.
>
> FAIL: semok/thirtynine.stp
> can't access identifier '$prev' at .../semok/thirtynine.stp:6:40
I'd guess this is a debuginfo problem.
> FAIL: systemtap.stress/current.stp compilation
> can't probe kernel.function("__switch_to").call
> need to adapt for arm
File a PR on this one.
> FAIL: unprivileged embedded C: no embedded C: --unprivileged: inet_get_ip_source(long)
> FAIL: unprivileged embedded C: no embedded C: --unprivileged: get_ip(long)
I've always been fuzzy on what exactly these errors mean.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-23 20:55 ` David Smith
@ 2012-02-23 22:06 ` William Cohen
2012-02-23 22:56 ` David Smith
2012-02-23 22:12 ` David Smith
1 sibling, 1 reply; 14+ messages in thread
From: William Cohen @ 2012-02-23 22:06 UTC (permalink / raw)
To: David Smith; +Cc: systemtap
On 02/23/2012 03:54 PM, David Smith wrote:
> On 02/23/2012 01:06 PM, William Cohen wrote:
Hi David,
Thanks for the comments/questions.
>
>> I reviewed the SystemTap testsuite failures for Fedora 15 hard float running on ARM. You can see the recent ARM test results in dejazilla at:
>>
>> http://web.elastic.org/~dejazilla/viewsummary.php?_offset=0&_limit=40&_sort=1A&summary=&age=&rg=&tool=&variant=%3D%27armv7l-unknown-linux-gnu%27&versions=&pass=&fail=&kpass=&kfail=&xpass=&xfail=&untested=&unresolved=&unsupported=&warning=&error=
>
>
> Here are some notes on certain tests:
>
>> FAIL: ipaddr_IPv4_recvmsg find 'nc'
>> doesn't seem to find /usr/bin/nc, but nc rpm has been installed on machine
I need to pay attention to editing. I installed nc on the machine after I realized why the test was failing, but didn't write things correctly after trying stuff. The test passes after installing the nc rpm.
>
>
> That's odd. That test tries to find nc by running "which nc". If that
> succeeds, it assumes nc is there. Does "which nc" find /usr/bin/nc and
> return a 0 exit code?
>
>> FAIL: vma_vdsodefault
>> vma_vdso.stp uses uaddr() which didn't work on arm.
>
>
> Hmm, can you tell in systemtap.log what part of 'uaddr()' didn't work?
The log wasn't too helpful. When running the test by hand. Looks like umodename(uaddrr()) == "<unknown>", so getting from
printf("%s@%x unknown\n", name, uaddr());
>>
>
>> FAIL: uprobeslibgcc-O3default-prelink-debug prelink ./libuprobeslibgcc-O3default-prelink-debug.so
>> FAIL: uprobeslibgcc-O3default-prelink-sep-debug prelink ./libuprobeslibgcc-O3default-prelink-sep-debug.so
>> FAIL: uprobeslibgcc-O3default-prelink-sep-debug-after prelink ./libuprobeslibgcc-O3default-prelink-sep-debug-after.so
>> uprobes not available on arm
>
>
> This is odd. I would have thought the testsuite would have realized
> this platform didn't have uprobes, and not run the test at all. Which
> .exp is this, exelib.exp?
Yes, it appears to be running:
systemtap.exelib/exelib.exp ...
>
>> FAIL: buildok/syscalls-arch-detailed.stp
>> unable to probe syscall.sigaltstack.return
>> ARM doesn't have a sys_sigaltstack() function in the kernel.
>
>
> That's PR13480.
>
>> FAIL: buildok/tcp-all-probes.stp
>> FAIL: buildok/tcp-detailed.stp
>> unable to get identifier '$optname' tapset/tcp.stp:369:27
>
>
> Hmm, this one looks like a debuginfo problem. Could you show me the
> output of:
>
> # stap -L 'kernel.function("tcp_setsockopt")
$ ../install/bin/stap -L 'kernel.function("tcp_setsockopt")'
kernel.function("tcp_setsockopt@net/ipv4/tcp.c:2406") $optlen:unsigned int $sk:struct sock*
>
>> FAIL: buildok/twentyeightprime.stp
>> CONFIG_UTRACE not available (seems like that should be UNTESTED)
>
>
> Actually it should be KFAIL. I'll fix this.
>
>>
>> FAIL: semok/thirtynine.stp
>> can't access identifier '$prev' at .../semok/thirtynine.stp:6:40
>
>
> I'd guess this is a debuginfo problem.
>
>> FAIL: systemtap.stress/current.stp compilation
>> can't probe kernel.function("__switch_to").call
>> need to adapt for arm
>
>
> File a PR on this one.
Looks very similar to PR4331 - systemtap.stress/current.stp need to be updated for s390x
Made clone: PR13734 - systemtap.stress/current.stp need to be updated for arm
>
>> FAIL: unprivileged embedded C: no embedded C: --unprivileged: inet_get_ip_source(long)
>> FAIL: unprivileged embedded C: no embedded C: --unprivileged: get_ip(long)
>
>
> I've always been fuzzy on what exactly these errors mean.
I wasn't too clear on the last two, so I didn't comment on them either. :/
-Will
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-23 20:55 ` David Smith
2012-02-23 22:06 ` William Cohen
@ 2012-02-23 22:12 ` David Smith
1 sibling, 0 replies; 14+ messages in thread
From: David Smith @ 2012-02-23 22:12 UTC (permalink / raw)
To: William Cohen; +Cc: systemtap
On 02/23/2012 02:54 PM, David Smith wrote:
> On 02/23/2012 01:06 PM, William Cohen wrote:
>
>> FAIL: buildok/twentyeightprime.stp
>> CONFIG_UTRACE not available (seems like that should be UNTESTED)
>
> Actually it should be KFAIL. I'll fix this.
Fixed in commit b0a5a91.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-23 22:06 ` William Cohen
@ 2012-02-23 22:56 ` David Smith
2012-02-24 16:04 ` David Smith
0 siblings, 1 reply; 14+ messages in thread
From: David Smith @ 2012-02-23 22:56 UTC (permalink / raw)
To: William Cohen; +Cc: systemtap
On 02/23/2012 04:06 PM, William Cohen wrote:
> On 02/23/2012 03:54 PM, David Smith wrote:
>> On 02/23/2012 01:06 PM, William Cohen wrote:
>
> Hi David,
>
> Thanks for the comments/questions.
>
>>
>>> I reviewed the SystemTap testsuite failures for Fedora 15 hard float running on ARM. You can see the recent ARM test results in dejazilla at:
>>>
>>> http://web.elastic.org/~dejazilla/viewsummary.php?_offset=0&_limit=40&_sort=1A&summary=&age=&rg=&tool=&variant=%3D%27armv7l-unknown-linux-gnu%27&versions=&pass=&fail=&kpass=&kfail=&xpass=&xfail=&untested=&unresolved=&unsupported=&warning=&error=
>>
>>
>> Here are some notes on certain tests:
>>
>>> FAIL: ipaddr_IPv4_recvmsg find 'nc'
>>> doesn't seem to find /usr/bin/nc, but nc rpm has been installed on machine
>
> I need to pay attention to editing. I installed nc on the machine after I realized why the test was failing, but didn't write things correctly after trying stuff. The test passes after installing the nc rpm.
Great, I thought that test should have worked there.
>>> FAIL: vma_vdsodefault
>>> vma_vdso.stp uses uaddr() which didn't work on arm.
>>
>>
>> Hmm, can you tell in systemtap.log what part of 'uaddr()' didn't work?
>
> The log wasn't too helpful. When running the test by hand. Looks like umodename(uaddrr()) == "<unknown>", so getting from
>
> printf("%s@%x unknown\n", name, uaddr());
Hmm, I'll try looking at this one some more.
>>> FAIL: uprobeslibgcc-O3default-prelink-debug prelink ./libuprobeslibgcc-O3default-prelink-debug.so
>>> FAIL: uprobeslibgcc-O3default-prelink-sep-debug prelink ./libuprobeslibgcc-O3default-prelink-sep-debug.so
>>> FAIL: uprobeslibgcc-O3default-prelink-sep-debug-after prelink ./libuprobeslibgcc-O3default-prelink-sep-debug-after.so
>>> uprobes not available on arm
>>
>>
>> This is odd. I would have thought the testsuite would have realized
>> this platform didn't have uprobes, and not run the test at all. Which
>> .exp is this, exelib.exp?
>
> Yes, it appears to be running:
>
> systemtap.exelib/exelib.exp ...
Ah, I see what this one is doing now. I'll bet prelink isn't available
on arm. This testcase builds an exe, prelinks it, then does skip the
actual systemtap tests if !uprobes.
Is prelink present on your arm system?
Since prelink isn't present on ia64 either, it might be worthwhile to
have this testcase check for prelink.
>>> FAIL: buildok/tcp-all-probes.stp
>>> FAIL: buildok/tcp-detailed.stp
>>> unable to get identifier '$optname' tapset/tcp.stp:369:27
>>
>>
>> Hmm, this one looks like a debuginfo problem. Could you show me the
>> output of:
>>
>> # stap -L 'kernel.function("tcp_setsockopt")
>
> $ ../install/bin/stap -L 'kernel.function("tcp_setsockopt")'
> kernel.function("tcp_setsockopt@net/ipv4/tcp.c:2406") $optlen:unsigned int $sk:struct sock*
Yep, looks like bad debuginfo. That's missing several options, here's
the definition:
static int do_tcp_setsockopt(struct sock *sk, int level,
int optname, char __user *optval, unsigned int optlen)
>>> FAIL: systemtap.stress/current.stp compilation
>>> can't probe kernel.function("__switch_to").call
>>> need to adapt for arm
>>
>>
>> File a PR on this one.
>
>
> Looks very similar to PR4331 - systemtap.stress/current.stp need to be updated for s390x
> Made clone: PR13734 - systemtap.stress/current.stp need to be updated for arm
Great.
>>> FAIL: unprivileged embedded C: no embedded C: --unprivileged: inet_get_ip_source(long)
>>> FAIL: unprivileged embedded C: no embedded C: --unprivileged: get_ip(long)
>>
>>
>> I've always been fuzzy on what exactly these errors mean.
>
> I wasn't too clear on the last two, so I didn't comment on them either. :/
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-23 22:56 ` David Smith
@ 2012-02-24 16:04 ` David Smith
2012-02-24 18:27 ` William Cohen
0 siblings, 1 reply; 14+ messages in thread
From: David Smith @ 2012-02-24 16:04 UTC (permalink / raw)
To: William Cohen; +Cc: systemtap
On 02/23/2012 04:55 PM, David Smith wrote:
> On 02/23/2012 04:06 PM, William Cohen wrote:
>
>> On 02/23/2012 03:54 PM, David Smith wrote:
>>> On 02/23/2012 01:06 PM, William Cohen wrote:
>>
>> Hi David,
>>
>> Thanks for the comments/questions.
>>
>>>
>>>> I reviewed the SystemTap testsuite failures for Fedora 15 hard float running on ARM. You can see the recent ARM test results in dejazilla at:
>>>>
>>>> http://web.elastic.org/~dejazilla/viewsummary.php?_offset=0&_limit=40&_sort=1A&summary=&age=&rg=&tool=&variant=%3D%27armv7l-unknown-linux-gnu%27&versions=&pass=&fail=&kpass=&kfail=&xpass=&xfail=&untested=&unresolved=&unsupported=&warning=&error=
>>>
>>>
>>>> FAIL: vma_vdsodefault
>>>> vma_vdso.stp uses uaddr() which didn't work on arm.
>>>
>>>
>>> Hmm, can you tell in systemtap.log what part of 'uaddr()' didn't work?
>>
>> The log wasn't too helpful. When running the test by hand. Looks like umodename(uaddrr()) == "<unknown>", so getting from
>>
>> printf("%s@%x unknown\n", name, uaddr());
>
>
> Hmm, I'll try looking at this one some more.
The first thing we need to do here is figure out which is really
failing, uaddr() or umodname(). Could you change the test to just print
out the return value of uaddr() to see what it is returning?
>>>> FAIL: uprobeslibgcc-O3default-prelink-debug prelink ./libuprobeslibgcc-O3default-prelink-debug.so
>>>> FAIL: uprobeslibgcc-O3default-prelink-sep-debug prelink ./libuprobeslibgcc-O3default-prelink-sep-debug.so
>>>> FAIL: uprobeslibgcc-O3default-prelink-sep-debug-after prelink ./libuprobeslibgcc-O3default-prelink-sep-debug-after.so
>>>> uprobes not available on arm
>>>
>>>
>>> This is odd. I would have thought the testsuite would have realized
>>> this platform didn't have uprobes, and not run the test at all. Which
>>> .exp is this, exelib.exp?
>>
>> Yes, it appears to be running:
>>
>> systemtap.exelib/exelib.exp ...
>
> Ah, I see what this one is doing now. I'll bet prelink isn't available
> on arm. This testcase builds an exe, prelinks it, then does skip the
> actual systemtap tests if !uprobes.
>
> Is prelink present on your arm system?
>
> Since prelink isn't present on ia64 either, it might be worthwhile to
> have this testcase check for prelink.
Commit 164901b changes exelib.exp to only run the prelink tests if
prelink exists on the system. Try the test again and see if it works
better.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-24 16:04 ` David Smith
@ 2012-02-24 18:27 ` William Cohen
2012-02-24 19:28 ` David Smith
0 siblings, 1 reply; 14+ messages in thread
From: William Cohen @ 2012-02-24 18:27 UTC (permalink / raw)
To: David Smith; +Cc: systemtap
On 02/24/2012 11:03 AM, David Smith wrote:
> On 02/23/2012 04:55 PM, David Smith wrote:
>
>> On 02/23/2012 04:06 PM, William Cohen wrote:
>>
>>> On 02/23/2012 03:54 PM, David Smith wrote:
>>>> On 02/23/2012 01:06 PM, William Cohen wrote:
>>>
>>> Hi David,
>>>
>>> Thanks for the comments/questions.
>>>
>>>>
>>>>> I reviewed the SystemTap testsuite failures for Fedora 15 hard float running on ARM. You can see the recent ARM test results in dejazilla at:
>>>>>
>>>>> http://web.elastic.org/~dejazilla/viewsummary.php?_offset=0&_limit=40&_sort=1A&summary=&age=&rg=&tool=&variant=%3D%27armv7l-unknown-linux-gnu%27&versions=&pass=&fail=&kpass=&kfail=&xpass=&xfail=&untested=&unresolved=&unsupported=&warning=&error=
>>>>
>>>>
>
>
>>>>> FAIL: vma_vdsodefault
>>>>> vma_vdso.stp uses uaddr() which didn't work on arm.
>>>>
>>>>
>>>> Hmm, can you tell in systemtap.log what part of 'uaddr()' didn't work?
>>>
>>> The log wasn't too helpful. When running the test by hand. Looks like umodename(uaddrr()) == "<unknown>", so getting from
>>>
>>> printf("%s@%x unknown\n", name, uaddr());
>>
>>
>> Hmm, I'll try looking at this one some more.
>
>
> The first thing we need to do here is figure out which is really
> failing, uaddr() or umodname(). Could you change the test to just print
> out the return value of uaddr() to see what it is returning?
Added the following to the vma_vdso.stp just inside the (target() == pid())
+ printf("%s umodname(uaddr()) = umodname(%x) = %s\n",
+ name, uaddr(), umodname(uaddr()));
$ ../install/bin/stap ../systemtap/testsuite/systemtap.base/vma_vdso.stp -c testsuite/vma_vdsodefault.exe
clock_gettime umodname(uaddr()) = umodname(401096ec) = <unknown>
clock_gettime@401096ec unknown
getuid umodname(uaddr()) = umodname(40254e10) = <unknown>
getuid@40254e10 unknown
getuid umodname(uaddr()) = umodname(40221f5c) = <unknown>
getuid@40221f5c unknown
Below is the maps for the process to see where those addresses would map. The results of uaddr() do not look correct.
$ more /proc/8622/maps
00008000-00009000 r-xp 00000000 08:10 3540441 /media/greatplains/wcohen/syste
mtap_write/obj/testsuite/vma_vdsodefault.exe
00010000-00011000 rw-p 00000000 08:10 3540441 /media/greatplains/wcohen/syste
mtap_write/obj/testsuite/vma_vdsodefault.exe
40000000-4001d000 r-xp 00000000 08:01 1815738 /lib/ld-2.14.1.so
4001d000-40020000 rw-p 00000000 00:00 0
40024000-40025000 r--p 0001c000 08:01 1815738 /lib/ld-2.14.1.so
40025000-40026000 rw-p 0001d000 08:01 1815738 /lib/ld-2.14.1.so
40032000-40038000 r-xp 00000000 08:01 1815726 /lib/librt-2.14.1.so
40038000-4003f000 ---p 00006000 08:01 1815726 /lib/librt-2.14.1.so
4003f000-40040000 r--p 00005000 08:01 1815726 /lib/librt-2.14.1.so
40040000-40041000 rw-p 00006000 08:01 1815726 /lib/librt-2.14.1.so
40041000-400ac000 r-xp 00000000 08:01 1815692 /lib/libm-2.14.1.so
400ac000-400b3000 ---p 0006b000 08:01 1815692 /lib/libm-2.14.1.so
400b3000-400b4000 r--p 0006a000 08:01 1815692 /lib/libm-2.14.1.so
400b4000-400b5000 rw-p 0006b000 08:01 1815692 /lib/libm-2.14.1.so
400b5000-401e3000 r-xp 00000000 08:01 1815601 /lib/libc-2.14.1.so
401e3000-401ea000 ---p 0012e000 08:01 1815601 /lib/libc-2.14.1.so
401ea000-401ec000 r--p 0012d000 08:01 1815601 /lib/libc-2.14.1.so
401ec000-401ed000 rw-p 0012f000 08:01 1815601 /lib/libc-2.14.1.so
401ed000-401f0000 rw-p 00000000 00:00 0
401f0000-401fa000 r-xp 00000000 08:01 1815713 /lib/libgcc_s-4.6.1-20110908.so
.1
401fa000-40201000 ---p 0000a000 08:01 1815713 /lib/libgcc_s-4.6.1-20110908.so
.1
40201000-40202000 rw-p 00009000 08:01 1815713 /lib/libgcc_s-4.6.1-20110908.so
.1
40202000-40216000 r-xp 00000000 08:01 1815734 /lib/libpthread-2.14.1.so
40216000-4021d000 ---p 00014000 08:01 1815734 /lib/libpthread-2.14.1.so
4021d000-4021e000 r--p 00013000 08:01 1815734 /lib/libpthread-2.14.1.so
4021e000-4021f000 rw-p 00014000 08:01 1815734 /lib/libpthread-2.14.1.so
4021f000-40221000 rw-p 00000000 00:00 0
befdf000-bf000000 rw-p 00000000 00:00 0 [stack]
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]
>
>>>>> FAIL: uprobeslibgcc-O3default-prelink-debug prelink ./libuprobeslibgcc-O3default-prelink-debug.so
>>>>> FAIL: uprobeslibgcc-O3default-prelink-sep-debug prelink ./libuprobeslibgcc-O3default-prelink-sep-debug.so
>>>>> FAIL: uprobeslibgcc-O3default-prelink-sep-debug-after prelink ./libuprobeslibgcc-O3default-prelink-sep-debug-after.so
>>>>> uprobes not available on arm
...
>
> Commit 164901b changes exelib.exp to only run the prelink tests if
> prelink exists on the system. Try the test again and see if it works
> better.
>
Prelink isn't currently on the ARM fedora. It might be there in the future. Commit 164901b eliminates those failures on the ARM.
-Will
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-24 18:27 ` William Cohen
@ 2012-02-24 19:28 ` David Smith
2012-02-24 21:49 ` William Cohen
2012-02-25 19:40 ` Mark Wielaard
0 siblings, 2 replies; 14+ messages in thread
From: David Smith @ 2012-02-24 19:28 UTC (permalink / raw)
To: William Cohen; +Cc: systemtap
On 02/24/2012 12:26 PM, William Cohen wrote:
> On 02/24/2012 11:03 AM, David Smith wrote:
>> On 02/23/2012 04:55 PM, David Smith wrote:
>>
>>> On 02/23/2012 04:06 PM, William Cohen wrote:
>>>
>>>> On 02/23/2012 03:54 PM, David Smith wrote:
>>>>> On 02/23/2012 01:06 PM, William Cohen wrote:
>>>>
>>>> Hi David,
>>>>
>>>> Thanks for the comments/questions.
>>>>
>>>>>
>>>>>> I reviewed the SystemTap testsuite failures for Fedora 15 hard float running on ARM. You can see the recent ARM test results in dejazilla at:
>>>>>>
>>>>>> http://web.elastic.org/~dejazilla/viewsummary.php?_offset=0&_limit=40&_sort=1A&summary=&age=&rg=&tool=&variant=%3D%27armv7l-unknown-linux-gnu%27&versions=&pass=&fail=&kpass=&kfail=&xpass=&xfail=&untested=&unresolved=&unsupported=&warning=&error=
>>>>>
>>>>>
>>
>>
>>>>>> FAIL: vma_vdsodefault
>>>>>> vma_vdso.stp uses uaddr() which didn't work on arm.
>>>>>
>>>>>
>>>>> Hmm, can you tell in systemtap.log what part of 'uaddr()' didn't work?
>>>>
>>>> The log wasn't too helpful. When running the test by hand. Looks like umodename(uaddrr()) == "<unknown>", so getting from
>>>>
>>>> printf("%s@%x unknown\n", name, uaddr());
>>>
>>>
>>> Hmm, I'll try looking at this one some more.
>>
>>
>> The first thing we need to do here is figure out which is really
>> failing, uaddr() or umodname(). Could you change the test to just print
>> out the return value of uaddr() to see what it is returning?
>
> Added the following to the vma_vdso.stp just inside the (target() == pid())
>
> + printf("%s umodname(uaddr()) = umodname(%x) = %s\n",
> + name, uaddr(), umodname(uaddr()));
>
>
> $ ../install/bin/stap ../systemtap/testsuite/systemtap.base/vma_vdso.stp -c testsuite/vma_vdsodefault.exe
> clock_gettime umodname(uaddr()) = umodname(401096ec) = <unknown>
> clock_gettime@401096ec unknown
> getuid umodname(uaddr()) = umodname(40254e10) = <unknown>
> getuid@40254e10 unknown
> getuid umodname(uaddr()) = umodname(40221f5c) = <unknown>
> getuid@40221f5c unknown
>
> Below is the maps for the process to see where those addresses would map. The results of uaddr() do not look correct.
...
Interesting. So we got an address, but not a good address. Here's the
source of uaddr():
function uaddr:long()
%{ /* pure */ /* myproc-unprivileged */
struct pt_regs *uregs;
if (CONTEXT->probe_flags & _STP_PROBE_STATE_USER_MODE)
uregs = CONTEXT->uregs;
else
uregs = _stp_current_pt_regs();
if (uregs)
THIS->__retvalue = (int64_t) REG_IP(uregs);
else
THIS->__retvalue = 0;
%}
There are basically 3 possibilities of error here:
1) We're getting a bad uregs pointer from the context structure
2) We're getting a bad uregs pointer from the _stp_current_pt_regs().
3) REG_IP() isn't interpreting the good uregs pointer correctly
If you want to track this down further, first try to figure out where
we're getting uregs from.
>>>>>> FAIL: uprobeslibgcc-O3default-prelink-debug prelink ./libuprobeslibgcc-O3default-prelink-debug.so
>>>>>> FAIL: uprobeslibgcc-O3default-prelink-sep-debug prelink ./libuprobeslibgcc-O3default-prelink-sep-debug.so
>>>>>> FAIL: uprobeslibgcc-O3default-prelink-sep-debug-after prelink ./libuprobeslibgcc-O3default-prelink-sep-debug-after.so
>>>>>> uprobes not available on arm
>
> ...
>
>>
>> Commit 164901b changes exelib.exp to only run the prelink tests if
>> prelink exists on the system. Try the test again and see if it works
>> better.
>>
>
> Prelink isn't currently on the ARM fedora. It might be there in the future. Commit 164901b eliminates those failures on the ARM.
prelink being available on ARM in the future shouldn't be a problem.
That commit does a file existence check on prelink, not an arch check.
So if prelink shows up it will get used.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-24 19:28 ` David Smith
@ 2012-02-24 21:49 ` William Cohen
2012-02-25 19:40 ` Mark Wielaard
1 sibling, 0 replies; 14+ messages in thread
From: William Cohen @ 2012-02-24 21:49 UTC (permalink / raw)
To: David Smith; +Cc: systemtap
On 02/24/2012 02:27 PM, David Smith wrote:
> On 02/24/2012 12:26 PM, William Cohen wrote:
>
>> On 02/24/2012 11:03 AM, David Smith wrote:
>>> On 02/23/2012 04:55 PM, David Smith wrote:
>>>
>>>> On 02/23/2012 04:06 PM, William Cohen wrote:
>>>>
>>>>> On 02/23/2012 03:54 PM, David Smith wrote:
>>>>>> On 02/23/2012 01:06 PM, William Cohen wrote:
>>>>>
>>>>> Hi David,
>>>>>
>>>>> Thanks for the comments/questions.
>>>>>
>>>>>>
>>>>>>> I reviewed the SystemTap testsuite failures for Fedora 15 hard float running on ARM. You can see the recent ARM test results in dejazilla at:
>>>>>>>
>>>>>>> http://web.elastic.org/~dejazilla/viewsummary.php?_offset=0&_limit=40&_sort=1A&summary=&age=&rg=&tool=&variant=%3D%27armv7l-unknown-linux-gnu%27&versions=&pass=&fail=&kpass=&kfail=&xpass=&xfail=&untested=&unresolved=&unsupported=&warning=&error=
>>>>>>
>>>>>>
>>>
>>>
>>>>>>> FAIL: vma_vdsodefault
>>>>>>> vma_vdso.stp uses uaddr() which didn't work on arm.
>>>>>>
>>>>>>
>>>>>> Hmm, can you tell in systemtap.log what part of 'uaddr()' didn't work?
>>>>>
>>>>> The log wasn't too helpful. When running the test by hand. Looks like umodename(uaddrr()) == "<unknown>", so getting from
>>>>>
>>>>> printf("%s@%x unknown\n", name, uaddr());
>>>>
>>>>
>>>> Hmm, I'll try looking at this one some more.
>>>
>>>
>>> The first thing we need to do here is figure out which is really
>>> failing, uaddr() or umodname(). Could you change the test to just print
>>> out the return value of uaddr() to see what it is returning?
>>
>> Added the following to the vma_vdso.stp just inside the (target() == pid())
>>
>> + printf("%s umodname(uaddr()) = umodname(%x) = %s\n",
>> + name, uaddr(), umodname(uaddr()));
>>
>>
>> $ ../install/bin/stap ../systemtap/testsuite/systemtap.base/vma_vdso.stp -c testsuite/vma_vdsodefault.exe
>> clock_gettime umodname(uaddr()) = umodname(401096ec) = <unknown>
>> clock_gettime@401096ec unknown
>> getuid umodname(uaddr()) = umodname(40254e10) = <unknown>
>> getuid@40254e10 unknown
>> getuid umodname(uaddr()) = umodname(40221f5c) = <unknown>
>> getuid@40221f5c unknown
>>
>> Below is the maps for the process to see where those addresses would map. The results of uaddr() do not look correct.
>
>
> ...
>
> Interesting. So we got an address, but not a good address. Here's the
> source of uaddr():
>
> function uaddr:long()
> %{ /* pure */ /* myproc-unprivileged */
> struct pt_regs *uregs;
>
>
> if (CONTEXT->probe_flags & _STP_PROBE_STATE_USER_MODE)
> uregs = CONTEXT->uregs;
> else
> uregs = _stp_current_pt_regs();
>
> if (uregs)
> THIS->__retvalue = (int64_t) REG_IP(uregs);
> else
> THIS->__retvalue = 0;
> %}
>
> There are basically 3 possibilities of error here:
>
> 1) We're getting a bad uregs pointer from the context structure
> 2) We're getting a bad uregs pointer from the _stp_current_pt_regs().
> 3) REG_IP() isn't interpreting the good uregs pointer correctly
>
> If you want to track this down further, first try to figure out where
> we're getting uregs from.
It should be doing this code in kernel-space. Printed valude of user_mode() to verify. Ruled out #1. It is getting information from _stp_current_pt_regs().
I started taking a look at the uaddr() and umodname() code to see where they are getting things.
See where REG_IP() coming from for arm, runtime/regs.h:
#elif defined (__arm__)
#define REG_IP(regs) regs->ARM_pc
#define REG_SP(regs) regs->ARM_sp
#define REG_LINK(regs) regs->ARM_lr
See ARM_pc defined in:
http://lxr.linux.no/#linux+v3.2.7/arch/arm/include/asm/ptrace.h#L114
I will do some more looking around why this doesn't work this evening.
-Will
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-24 19:28 ` David Smith
2012-02-24 21:49 ` William Cohen
@ 2012-02-25 19:40 ` Mark Wielaard
2012-02-27 15:33 ` William Cohen
1 sibling, 1 reply; 14+ messages in thread
From: Mark Wielaard @ 2012-02-25 19:40 UTC (permalink / raw)
To: David Smith; +Cc: William Cohen, systemtap
On Fri, Feb 24, 2012 at 01:27:43PM -0600, David Smith wrote:
> On 02/24/2012 12:26 PM, William Cohen wrote:
> >>>>>> FAIL: vma_vdsodefault
> >>>>>> vma_vdso.stp uses uaddr() which didn't work on arm.
> >>>>>
> >>>>> Hmm, can you tell in systemtap.log what part of 'uaddr()' didn't work?
> >>>>
> >>>> The log wasn't too helpful. When running the test by hand. Looks like umodename(uaddrr()) == "<unknown>", so getting from
> >>>>
> >>>> printf("%s@%x unknown\n", name, uaddr());
> >>>
> >>> Hmm, I'll try looking at this one some more.
> >>
> >> The first thing we need to do here is figure out which is really
> >> failing, uaddr() or umodname(). Could you change the test to just print
> >> out the return value of uaddr() to see what it is returning?
> >
> > Added the following to the vma_vdso.stp just inside the (target() == pid())
> >
> > + printf("%s umodname(uaddr()) = umodname(%x) = %s\n",
> > + name, uaddr(), umodname(uaddr()));
> >
> >
> > $ ../install/bin/stap ../systemtap/testsuite/systemtap.base/vma_vdso.stp -c testsuite/vma_vdsodefault.exe
> > clock_gettime umodname(uaddr()) = umodname(401096ec) = <unknown>
> > clock_gettime@401096ec unknown
> > getuid umodname(uaddr()) = umodname(40254e10) = <unknown>
> > getuid@40254e10 unknown
> > getuid umodname(uaddr()) = umodname(40221f5c) = <unknown>
> > getuid@40221f5c unknown
> >
> > Below is the maps for the process to see where those addresses would map. The results of uaddr() do not look correct.
>
>
> ...
>
> Interesting. So we got an address, but not a good address.
Note that this test explicitly tries to test an address has an known
module name, even if it is in the vdso, which is normally randomly
allocated in the process address space.
In the vma_vdso.c test program we see it uses a trick to make sure
we end up in the vdso (this depends on the implementation of clock_gettime
on the platform, so make sure on ARM this also results into actually
going into the vdso).
/* Give an invalid clockid_t on purpose so the vdso has to call
through to the kernel syscall. */
The testcase also tests the testuid call in two different ways.
Maye that is an easier case on ARM?
Then in vma_vdso.stp we see that the probes are in kernel space:
probe syscall.clock_gettime, syscall.getuid
It would surprise me if the uaddr() was really wrong, but it could
be. I suspect that the uaddr() is in the vdso and the vdso tracker
is broken on ARM.
A simpler test would be running this:
stap -e 'probe syscall.clock_gettime, syscall.getuidr
{ if (pid() == target()) printf("%s 0x%x in %s\n", name, uaddr(),
umodname(uaddr())) }' \
-c testsuite/vma_vdso-m64.exe
Which on x86_64 gives:
clock_gettime 0x7fff689ff9cf in vdso
getuid 0x3c5c0ed819 in /usr/lib64/libc-2.15.so
getuid 0x3c5c0bb007 in /usr/lib64/libc-2.15.so
Does that fail for all invocations on ARM?
If it is the vdso tracker then you want to take a look at
runtime/vma.c _stp_vma_match_vdso will give some debug output
with stap -DDEBUG_TASK_FINDER_VMA
Cheers,
Mark
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-25 19:40 ` Mark Wielaard
@ 2012-02-27 15:33 ` William Cohen
2012-02-27 16:10 ` Mark Wielaard
0 siblings, 1 reply; 14+ messages in thread
From: William Cohen @ 2012-02-27 15:33 UTC (permalink / raw)
To: Mark Wielaard; +Cc: David Smith, systemtap
On 02/25/2012 02:39 PM, Mark Wielaard wrote:
> A simpler test would be running this:
>
> stap -e 'probe syscall.clock_gettime, syscall.getuidr
> { if (pid() == target()) printf("%s 0x%x in %s\n", name, uaddr(),
> umodname(uaddr())) }' \
> -c testsuite/vma_vdso-m64.exe
>
> Which on x86_64 gives:
>
> clock_gettime 0x7fff689ff9cf in vdso
> getuid 0x3c5c0ed819 in /usr/lib64/libc-2.15.so
> getuid 0x3c5c0bb007 in /usr/lib64/libc-2.15.so
>
> Does that fail for all invocations on ARM?
>
> If it is the vdso tracker then you want to take a look at
> runtime/vma.c _stp_vma_match_vdso will give some debug output
> with stap -DDEBUG_TASK_FINDER_VMA
>
> Cheers,
>
> Mark
Hi Mark,
Does this this test need the uprobes support for this test to work?
Below is the output for 2.6.42.3-2.fc15.armv7hl.tegra kernel which doesn't have uprobes support:
$ stap -e 'probe syscall.clock_gettime, syscall.getuid
{ if (pid() == target()) printf("%s 0x%x in %s\n", name, uaddr(),
umodname(uaddr())) }' -c testsuite/vma_vdsodefault.exe
clock_gettime 0x4010d6ec in <unknown>
getuid 0x40258e10 in <unknown>
getuid 0x40225f5c in <unknown>
-Will
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-27 15:33 ` William Cohen
@ 2012-02-27 16:10 ` Mark Wielaard
2012-02-27 21:54 ` Mark Wielaard
0 siblings, 1 reply; 14+ messages in thread
From: Mark Wielaard @ 2012-02-27 16:10 UTC (permalink / raw)
To: William Cohen; +Cc: David Smith, systemtap
On Mon, 2012-02-27 at 10:33 -0500, William Cohen wrote:
> On 02/25/2012 02:39 PM, Mark Wielaard wrote:
>
> > A simpler test would be running this:
> >
> > stap -e 'probe syscall.clock_gettime, syscall.getuidr
> > { if (pid() == target()) printf("%s 0x%x in %s\n", name, uaddr(),
> > umodname(uaddr())) }' \
> > -c testsuite/vma_vdso-m64.exe
> >
> > Which on x86_64 gives:
> >
> > clock_gettime 0x7fff689ff9cf in vdso
> > getuid 0x3c5c0ed819 in /usr/lib64/libc-2.15.so
> > getuid 0x3c5c0bb007 in /usr/lib64/libc-2.15.so
> >
> > Does that fail for all invocations on ARM?
> >
> > If it is the vdso tracker then you want to take a look at
> > runtime/vma.c _stp_vma_match_vdso will give some debug output
> > with stap -DDEBUG_TASK_FINDER_VMA
> >
> Does this this test need the uprobes support for this test to work?
Maybe... I am a little fuzzy on the details of when/how vma tracking is
triggered. Technically vma tracking doesn't need uprobes. But it might
be that vma tracking is only enabled/started if uprobes are active. You
might have to look with -DDEBUG_TASK_FINDER_VMA to see what is
happening.
> Below is the output for 2.6.42.3-2.fc15.armv7hl.tegra kernel which doesn't have uprobes support:
>
> $ stap -e 'probe syscall.clock_gettime, syscall.getuid
> { if (pid() == target()) printf("%s 0x%x in %s\n", name, uaddr(),
> umodname(uaddr())) }' -c testsuite/vma_vdsodefault.exe
> clock_gettime 0x4010d6ec in <unknown>
> getuid 0x40258e10 in <unknown>
> getuid 0x40225f5c in <unknown>
It is surprising none of these addresses map to a known vma map name. I
would expect at least some of them to come through libc and/or the
executable itself. You might want to extend the test scope to some other
(all?) syscalls and see which user address called into the kernel and
which umodname that corresponds to.
And maybe turn on -DDEBUG_TASK_FINDER_VMA to see which address ranges
are known to the stap runtime.
Cheers,
Mark
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-27 16:10 ` Mark Wielaard
@ 2012-02-27 21:54 ` Mark Wielaard
2012-02-27 22:20 ` William Cohen
0 siblings, 1 reply; 14+ messages in thread
From: Mark Wielaard @ 2012-02-27 21:54 UTC (permalink / raw)
To: William Cohen; +Cc: David Smith, systemtap
On Mon, Feb 27, 2012 at 05:10:08PM +0100, Mark Wielaard wrote:
> On Mon, 2012-02-27 at 10:33 -0500, William Cohen wrote:
> > Does this this test need the uprobes support for this test to work?
>
> Maybe... I am a little fuzzy on the details of when/how vma tracking is
> triggered. Technically vma tracking doesn't need uprobes. But it might
> be that vma tracking is only enabled/started if uprobes are active. You
> might have to look with -DDEBUG_TASK_FINDER_VMA to see what is
> happening.
I poked a bit myself on an arm setup. The vma tracker doesn't need
uprobes, but it does need the task finder, and runtime.h says:
#if (defined(CONFIG_UTRACE) || defined(STAPCONF_UTRACE_VIA_TRACEPOINTS) \
|| defined(STAPCONF_UTRACE_VIA_FTRACE))
#define HAVE_TASK_FINDER
#endif
So you do need some form of UTRACE.
Unfortunately my setup doesn't have that.
Does your kernel?
Cheers,
Mark
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
2012-02-27 21:54 ` Mark Wielaard
@ 2012-02-27 22:20 ` William Cohen
0 siblings, 0 replies; 14+ messages in thread
From: William Cohen @ 2012-02-27 22:20 UTC (permalink / raw)
To: Mark Wielaard; +Cc: David Smith, systemtap
On 02/27/2012 04:54 PM, Mark Wielaard wrote:
> On Mon, Feb 27, 2012 at 05:10:08PM +0100, Mark Wielaard wrote:
>> On Mon, 2012-02-27 at 10:33 -0500, William Cohen wrote:
>>> Does this this test need the uprobes support for this test to work?
>>
>> Maybe... I am a little fuzzy on the details of when/how vma tracking is
>> triggered. Technically vma tracking doesn't need uprobes. But it might
>> be that vma tracking is only enabled/started if uprobes are active. You
>> might have to look with -DDEBUG_TASK_FINDER_VMA to see what is
>> happening.
>
> I poked a bit myself on an arm setup. The vma tracker doesn't need
> uprobes, but it does need the task finder, and runtime.h says:
>
> #if (defined(CONFIG_UTRACE) || defined(STAPCONF_UTRACE_VIA_TRACEPOINTS) \
> || defined(STAPCONF_UTRACE_VIA_FTRACE))
> #define HAVE_TASK_FINDER
> #endif
>
> So you do need some form of UTRACE.
> Unfortunately my setup doesn't have that.
> Does your kernel?
>
> Cheers,
>
> Mark
Hi Mark,
My arm machine kernels don't have the UTRACE supoort either. I have the fedora 15 arm kernel (kernel-tegra-2.6.42.3-2.fc15.armv7hl) and the vanilla git tree kernel, 3.3.0-rc5+, on my machine.
-Will
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-02-27 22:20 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-23 19:06 Recent review of SystemTap test results on ARM running Fedora 15 hard float William Cohen
2012-02-23 20:55 ` David Smith
2012-02-23 22:06 ` William Cohen
2012-02-23 22:56 ` David Smith
2012-02-24 16:04 ` David Smith
2012-02-24 18:27 ` William Cohen
2012-02-24 19:28 ` David Smith
2012-02-24 21:49 ` William Cohen
2012-02-25 19:40 ` Mark Wielaard
2012-02-27 15:33 ` William Cohen
2012-02-27 16:10 ` Mark Wielaard
2012-02-27 21:54 ` Mark Wielaard
2012-02-27 22:20 ` William Cohen
2012-02-23 22:12 ` David Smith
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).