Test fails for Xen

[Brad Spencer <brad%anduin.eldar.org@localhost>]

I was looking at the failing tests on
https://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/ and was wondering
about two of them...

--------for amd64------------
Test case: usr.sbin/execsnoop/t_execsnoop/basic

Duration: 10.738846 seconds
Termination reason

FAILED: execsnoop does not work
Standard output stream

Executing command [ /bin/sh -c execsnoop >execsnoop.out 2>execsnoop.stderr & ]
root
root
root
root
root
root
root
root
root
root

Standard error stream

modstat: Modules can be autoloaded, but kern.module.autoload = 0.
dtrace: failed to initialize dtrace: Exec format error
--------------------

The execsnoop test case and the execsnoop command itself works fine for
me on my Xen/amd64 PV guest.  Further, the "Exec format error" message
suggests that something might be wrong on the testing system.  The test
itself has a, perhaps, overly complicated begin condition that uses a
number of modstat calls that could all probably be reduced to just a
"dtrace -l > /dev/null" call in the if block.  For this test to work,
the /dev/dtrace device will have to exist and either autoloading must be
enabled or the various dtrace modules must be loaded before the test is
started.  Is it possible for the testing system to be checked to see if
this is a artificial fail??



---------for amd64 ----
Test case: usr.bin/ztest/t_ztest/assert

Duration: 301.361784 seconds
Termination reason

FAILED: Test case timed out after 300 seconds
Standard output stream

Executing command [ /bin/sh -c mkdir /tmp/ztest ]
Executing command [ /bin/sh -c ztest -VVV -v10 -m2 -r12 -R3 -T 10 -f /tmp/ztest ]
-----------------------

It seems very unlikely that this test will ever complete in 300 second.
The ZFS ztest tester can be pretty brutal about what it does both in
terms of the amount of CPU it will use and the amount of memory.
Further, the "-T" runtime argument may not work entirely as one would
expect.  Running ztest tests on a couple of other systems, a FreeBSD one
and a ArchLinux one suggests that a simple understanding of what "-T"
means may not be correct.  It does seem likely that ztest has a bug in
it, as it tends to segfault for me.  That may be due to not being able
to give it enough resources, but on the other hand, it acts much better
when its automatic-random-killer setting is set to 0% (-k 0).  The PR
kern/53767 is mentioned in the test case but is was a while ago.

I would suggest that this test probably is not a good candidate for the
atf framework especially given the test that it is trying to do.

(As an aside, I did get a successful run of ztest with nearly the same
arguments as the atf test, except I added -k0 ..  however it took about
an hour to run on a single vcpu / 8GB Xen PV guest and ran the load up
to about 250 during some of the testing.  This does suggest that there
may be something wrong with the random killer code in ztest as the test
would never complete for me if that was set to be greater than 0% of the
time.  I have a typescript output of the run if anyone wants to see it.)





-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org