Re: testsuite summary report - ppc64

[David Smith <dsmith at redhat dot com>]

On 06/18/2010 11:43 AM, David Smith wrote:
> While I had access to a ppc64 machine to test PR11707, I went ahead and
> ran the full testsuite (results submitted to dejazilla also).

...

> Running /root/src/testsuite/systemtap.base/cmd_parse.exp ...
> FAIL: cmd_parse16: eof
> 
> - This appears to be a testcase problem.  Here's the associated output from
> systemtap.log:
> 
> Makefile:485: /usr/src/kernels/2.6.18-194.el5-ppc64/arch/ppc64/Makefile:
> No such file or directory
> make[3]: *** No rule to make target
> `/usr/src/kernels/2.6.18-194.el5-ppc64/arch/ppc64/Makefile'.  Stop.
> 
> We're looking for 'arch/ppc64/Makefile'.  The testcase expected 'uname
> -i' to return 'powerpc', not 'ppc64'.  By making the testcase change
> 'ppc64' into 'powerpc', this test passes.

PR11719 filed on this issue.

> Running /root/src/testsuite/systemtap.base/preprocessor.exp ...
> FAIL: preprocessor basic ops
> 
> This is another problem of 'ppc64' vs. 'powerpc'.  With the testcase
> mapping 'ppc64' to 'powerpc' this testcase passes.

PR11719 filed on this issue.

> Running /root/src/testsuite/systemtap.base/skipped.exp ...
> FAIL: skip tracking (4 0 0 0)
> 
> This appears to be a real problem.  Systemtap crashes:
> 
> Running /root/src/testsuite/systemtap.base/skipped.exp ...
> /tmp/stapxeJfkd/stap_b0646c5096a36184c41a7a9f0f6185ff_633.c: In function
> ‘enter_profile_probes’:
> /tmp/stapxeJfkd/stap_b0646c5096a36184c41a7a9f0f6185ff_633.c:346:
> internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
> Preprocessed source stored into /tmp/ccXKVnJ7.out file, please attach
> this to your bugreport.
> make[4]: ***
> [/tmp/stapxeJfkd/stap_b0646c5096a36184c41a7a9f0f6185ff_633.o] Error 1
> make[3]: *** [_module_/tmp/stapxeJfkd] Error 2
> Pass 4: compilation failed.  Try again with another '--vp 0001' option.
> FAIL: skip tracking (4 0 0 0)

This is actually gcc crashing.  PR11720 filed.

> Running /root/src/testsuite/systemtap.context/usymbols.exp ...
> FAIL: usymbols
> 
> This one is similar to the pointer_array.stp problem.  The testcase uses
> syscall.rt_sigaction.  Because ppc64 has a 32-bit userspace,
> syscall.rt_sigaction doesn't get called - syscall.rt_sigaction32 does.

PR11722 filed on this issue.

> However, this testcase looks like it has a problem to me.  It directly
> accesses $act->sa_handler, but since $act is 'const struct sigaction
> __user *act', it shouldn't really do that on *any* platform (without
> calling _stp_copy_from_user)
> 
> Hmm, is there some way to get the translator to give an error if we try
> to access a __user pointer directly?

PR11721 filed on accessing '__user' memory incorrectly.

> Running /root/src/testsuite/systemtap.pass1-4/transok.exp ...
> FAIL: transok/buildko.stp
> 
> This is a testcase problem (that also happens on x86_64).  buildko.stp
> tries a test that needs guru mode.

PR11723 filed on this one.

> Running /root/src/testsuite/systemtap.printf/bin6.exp ...
> FAIL: systemtap.printf/bin6.stp
> 
> This is a ppc64-specific problem.  The testcase reports:
> 
> line 2: expected "Binary static width default precision	:d:"
> Got "Binary static width default precision	:f:"

PR11725 filed on this one.

> Running /root/src/testsuite/systemtap.printf/memory1.exp ...
> FAIL: systemtap.printf/memory1.stp
> 
> This is a ppc64-specific problem.  The testcase won't compile, gets
> errors like the following:
> 
> /tmp/stapLgPkPY/stap_ed7d278c674d772665862eaeeaaaba1c_22694.c:1616:
> warning: format ‘%lld’ expects type ‘long long int’, but argument 4 has
> type ‘int64_t’

PR11726 filed on this one.

> Running /root/src/testsuite/systemtap.server/server.exp ...
> FAIL: buildok/memory-mmap.stp with server
> FAIL: buildok/nfs-fop.check_flags.stp with server
> FAIL: buildok/process_test.stp with server
> FAIL: buildok/scheduler-migrate.stp with server
> FAIL: buildok/signal-handle.stp with server
> FAIL: buildok/thirtythree.stp with server
> FAIL: buildok/tty-resize.stp with server
> 
> These all are KFAIL'ed when running buildok.exp (except for
> process_test.stp and thirtythree.stp), so they're ok.  We should
> probably make server.exp also KFAIL them.  See process_test.stp
> description earlier.  server.exp probably shouldn't execute
> thirtythree.stp, since it is really a shell script.

PR11727 filed on this issue.

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