Results of systemtap-20071124 snapshot on s390x

Results of systemtap-20071124 snapshot on s390x

[David Wilder]

                 === systemtap Summary ===

# of expected passes            479
# of unexpected failures        21
# of expected failures          154
# of unknown successes          1
# of known failures             5
# of untested testcases         3
# of unsupported tests          2


FAIL: K_MARKER04 compilation failed
FAIL: backtrace of yyy_func3 (2)
FAIL: print_stack of yyy_func3 (2)
FAIL: backtrace of yyy_func4.return (3)
FAIL: print_stack of yyy_func4.return (2)
FAIL: buildok/ioblock_test.stp
FAIL: buildok/nfs-all-probes.stp
FAIL: buildok/rpc-all-probes.stp
FAIL: buildok/scheduler-all-probes.stp
FAIL: buildok/seventeen.stp
FAIL: buildok/signal-all-probes.stp
FAIL: parseok/five.stp
FAIL: parseok/unparser.stp
FAIL: semok/twentyseven.stp
FAIL: iostat-scsi.stp
FAIL: key.stp
FAIL: keyhack.stp
FAIL: proc_snoop.stp
FAIL: systemtap.stress/current.stp compilation
FAIL: 32-bit rt_signal
FAIL rt_signal
FAIL: 32-bit signal
FAIL signal

Re: Results of systemtap-20071124 snapshot on s390x

[David Smith]

David Wilder wrote:
> FAIL: K_MARKER04 compilation failed

I've been meaning to ask about this for awhile, so here goes.  What
kernel is this using (and does this kernel have marker support)?  If
your kernel has markers, this could fail if the first marker found has
no arguments.  If your kernel doesn't have marker support, this test
shouldn't be run.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Results of systemtap-20071124 snapshot on s390x

[David Wilder]

David Smith wrote:
> David Wilder wrote:
>> FAIL: K_MARKER04 compilation failed
> 
> I've been meaning to ask about this for awhile, so here goes.  What
> kernel is this using (and does this kernel have marker support)?  If
> your kernel has markers, this could fail if the first marker found has
> no arguments.  If your kernel doesn't have marker support, this test
> shouldn't be run.
> 

I forgot to put the kernel version in the test report.  I am running 
2.4.24-rc3.  And CONFIG_MARKERS is "y".  I plan to take a look at the 
failure in the next day or so.  I will let you know what I find.

Re: Results of systemtap-20071124 snapshot on s390x

[David Smith]

David Wilder wrote:
> David Smith wrote:
>> David Wilder wrote:
>>> FAIL: K_MARKER04 compilation failed
>>
>> I've been meaning to ask about this for awhile, so here goes.  What
>> kernel is this using (and does this kernel have marker support)?  If
>> your kernel has markers, this could fail if the first marker found has
>> no arguments.  If your kernel doesn't have marker support, this test
>> shouldn't be run.
>>
> 
> I forgot to put the kernel version in the test report.  I am running
> 2.4.24-rc3.  And CONFIG_MARKERS is "y".  I plan to take a look at the
> failure in the next day or so.  I will let you know what I find.

Since your kernel does have markers, then I'll bet the first marker that
the test found doesn't actually have an argument (K_MARKER04 tests
whether the first argument can be accessed).

Can you post the K_MARKER04 section of systemtap.log?

If your problem is that the first marker found doesn't have an argument,
I'll need to look at changing the test somehow.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Results of systemtap-20071124 snapshot on s390x

[David Wilder]

David Smith wrote:
> David Wilder wrote:
>> David Smith wrote:
>>> David Wilder wrote:
>>>> FAIL: K_MARKER04 compilation failed
>>> I've been meaning to ask about this for awhile, so here goes.  What
>>> kernel is this using (and does this kernel have marker support)?  If
>>> your kernel has markers, this could fail if the first marker found has
>>> no arguments.  If your kernel doesn't have marker support, this test
>>> shouldn't be run.
>>>
>> I forgot to put the kernel version in the test report.  I am running
>> 2.4.24-rc3.  And CONFIG_MARKERS is "y".  I plan to take a look at the
>> failure in the next day or so.  I will let you know what I find.
> 
> Since your kernel does have markers, then I'll bet the first marker that
> the test found doesn't actually have an argument (K_MARKER04 tests
> whether the first argument can be accessed).
> 
> Can you post the K_MARKER04 section of systemtap.log?
> 
> If your problem is that the first marker found doesn't have an argument,
> I'll need to look at changing the test somehow.
> 

Pass 1: parsed user script and 38 library script(s) in 
480usr/0sys/501real ms.^M
Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 
global(s) in 20usr/20sys/42real ms.^M
Pass 3: translated to C into 
"/tmp/stapsIbnv3/stap_be214f08543be97af4999459e36b103f_387.c" in 
0usr/0sys/1real ms.^M
Pass 4: compiled C into "stap_be214f08543be97af4999459e36b103f_387.ko" 
in 1170usr/300sys/1485real ms.^M
Pass 4: compilation failed.  Try again with more '-v' (verbose) options.^M
FAIL: K_MARKER04 compilation failed
Pass 1: parsed user script and 38 library script(s) in 
480usr/0sys/499real ms.^M
semantic error: invalid marker argument number: identifier '$arg200' at 
<input>:1:49^M
semantic error: no match for probe point while resolving probe point 
kernel.mark("core_marker_format")^M
Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0 
global(s) in 20usr/30sys/44real ms.^M
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.^M

Re: Results of systemtap-20071124 snapshot on s390x

[David Smith]

David Wilder wrote:
> David Smith wrote:
>> David Wilder wrote:
>>> David Smith wrote:
>>>> David Wilder wrote:
>>>>> FAIL: K_MARKER04 compilation failed
>>>> I've been meaning to ask about this for awhile, so here goes.  What
>>>> kernel is this using (and does this kernel have marker support)?  If
>>>> your kernel has markers, this could fail if the first marker found has
>>>> no arguments.  If your kernel doesn't have marker support, this test
>>>> shouldn't be run.
>>>>
>>> I forgot to put the kernel version in the test report.  I am running
>>> 2.4.24-rc3.  And CONFIG_MARKERS is "y".  I plan to take a look at the
>>> failure in the next day or so.  I will let you know what I find.
>>
>> Since your kernel does have markers, then I'll bet the first marker that
>> the test found doesn't actually have an argument (K_MARKER04 tests
>> whether the first argument can be accessed).
>>
>> Can you post the K_MARKER04 section of systemtap.log?
>>
>> If your problem is that the first marker found doesn't have an argument,
>> I'll need to look at changing the test somehow.
>>
> 
> Pass 1: parsed user script and 38 library script(s) in
> 480usr/0sys/501real ms.^M
> Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0
> global(s) in 20usr/20sys/42real ms.^M
> Pass 3: translated to C into
> "/tmp/stapsIbnv3/stap_be214f08543be97af4999459e36b103f_387.c" in
> 0usr/0sys/1real ms.^M
> Pass 4: compiled C into "stap_be214f08543be97af4999459e36b103f_387.ko"
> in 1170usr/300sys/1485real ms.^M
> Pass 4: compilation failed.  Try again with more '-v' (verbose) options.^M
> FAIL: K_MARKER04 compilation failed
> Pass 1: parsed user script and 38 library script(s) in
> 480usr/0sys/499real ms.^M
> semantic error: invalid marker argument number: identifier '$arg200' at
> <input>:1:49^M
> semantic error: no match for probe point while resolving probe point
> kernel.mark("core_marker_format")^M
> Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0
> global(s) in 20usr/30sys/44real ms.^M
> Pass 2: analysis failed.  Try again with more '-v' (verbose) options.^M

Interesting.  The problem isn't that the marker the test used didn't
have an argument.  Otherwise, you would have gotten an error that looked
like the error message you got above (that comes from K_MARKER05). For
instance, here's what I get when I try to compile a probe that uses
'$arg1' when a marker doesn't have any arguments.

  # stap -e 'probe kernel.mark("mm_handle_fault_exit") { print($arg1)}'
  semantic error: invalid marker argument number: identifier '$arg1'
  at <input>:1:51 while resolving probe point
  kernel.mark("mm_handle_fault_exit")
  Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

What's weird is that only K_MARKER04 is failing.  K_MARKER01 and
K_MARKER02 compile correctly, yet K_MARKER04 doesn't compile.  The only
difference between K_MARKER02 and K_MARKER04 is that K_MARKER04 prints
$arg1.

Can you find a marker that has an argument and do a stap command like
this and report the output?

  # stap -vvv -p4 -e 'probe kernel.mark("FOO") { print($arg1) }'

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Results of systemtap-20071124 snapshot on s390x

[Frank Ch. Eigler]

David Smith <dsmith@redhat.com> writes:

> [...]  What's weird is that only K_MARKER04 is failing.  K_MARKER01
> and K_MARKER02 compile correctly, yet K_MARKER04 doesn't compile.
> The only difference between K_MARKER02 and K_MARKER04 is that
> K_MARKER04 prints $arg1. [...]

Remember "stap -u".

- FChE

Re: Results of systemtap-20071124 snapshot on s390x

[David Smith]

David Smith wrote:
> David Wilder wrote:
>
> Interesting.  The problem isn't that the marker the test used didn't
> have an argument.  Otherwise, you would have gotten an error that looked
> like the error message you got above (that comes from K_MARKER05). For
> instance, here's what I get when I try to compile a probe that uses
> '$arg1' when a marker doesn't have any arguments.
> 
>   # stap -e 'probe kernel.mark("mm_handle_fault_exit") { print($arg1)}'
>   semantic error: invalid marker argument number: identifier '$arg1'
>   at <input>:1:51 while resolving probe point
>   kernel.mark("mm_handle_fault_exit")
>   Pass 2: analysis failed.  Try again with more '-v' (verbose) options.
> 
> What's weird is that only K_MARKER04 is failing.  K_MARKER01 and
> K_MARKER02 compile correctly, yet K_MARKER04 doesn't compile.  The only
> difference between K_MARKER02 and K_MARKER04 is that K_MARKER04 prints
> $arg1.

I may have just found and fixed this.  In updating the marker test, I
started receiving a similar failure (on x86).  After debugging this a
bit, I found that it was because the marker had more than one string
argument - the translator was emitting invalid code in this case.  I've
fixed this now.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Results of systemtap-20071124 snapshot on s390x

[David Wilder]

David Smith wrote:
> David Smith wrote:
>> David Wilder wrote:
>>
>> Interesting.  The problem isn't that the marker the test used didn't
>> have an argument.  Otherwise, you would have gotten an error that looked
>> like the error message you got above (that comes from K_MARKER05). For
>> instance, here's what I get when I try to compile a probe that uses
>> '$arg1' when a marker doesn't have any arguments.
>>
>>   # stap -e 'probe kernel.mark("mm_handle_fault_exit") { print($arg1)}'
>>   semantic error: invalid marker argument number: identifier '$arg1'
>>   at <input>:1:51 while resolving probe point
>>   kernel.mark("mm_handle_fault_exit")
>>   Pass 2: analysis failed.  Try again with more '-v' (verbose) options.
>>
>> What's weird is that only K_MARKER04 is failing.  K_MARKER01 and
>> K_MARKER02 compile correctly, yet K_MARKER04 doesn't compile.  The only
>> difference between K_MARKER02 and K_MARKER04 is that K_MARKER04 prints
>> $arg1.
> 
> I may have just found and fixed this.  In updating the marker test, I
> started receiving a similar failure (on x86).  After debugging this a
> bit, I found that it was because the marker had more than one string
> argument - the translator was emitting invalid code in this case.  I've
> fixed this now.
> 

Thanks David, the Marker test is passing on s390 after your last change 
and after installing the following patches to the 2.6.24-rc3 kernel:

linux-kernel-markers-create-modpost-file.patch
markers-support-multiple-probes.patch