public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: David Smith <dsmith@redhat.com>
To: William Cohen <wcohen@redhat.com>
Cc: systemtap@sourceware.org
Subject: Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
Date: Thu, 23 Feb 2012 22:56:00 -0000	[thread overview]
Message-ID: <4F46C3F8.7080900@redhat.com> (raw)
In-Reply-To: <4F46B861.5060201@redhat.com>

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)

  reply	other threads:[~2012-02-23 22:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-23 19:06 William Cohen
2012-02-23 20:55 ` David Smith
2012-02-23 22:06   ` William Cohen
2012-02-23 22:56     ` David Smith [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F46C3F8.7080900@redhat.com \
    --to=dsmith@redhat.com \
    --cc=systemtap@sourceware.org \
    --cc=wcohen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).