This is more efficient since we can now start only the necessary number
of VMs instead of always forcing all VMs to start with one second delay.
This can also control the starting delay by keeping at most two VMs
starting at a time instead of using the hardcoded one second wait for
each consecutive VM.
Signed-off-by: Jouni Malinen <j@w1.fi>
Now that parallel-vm.py is actually stopping VMs as soon as they are not
needed for retries, it is not really an unexpected exit to see a VM exit
while test cases remain in the queue as long as at least that many VMs
remain running. Get rid of confusing 'unexpected exit' status from the
UI in such cases.
Fixes: 4aaddecdd8 ("tests: Handle test retries through the same queue")
Signed-off-by: Jouni Malinen <j@w1.fi>
This removes the separate rerun step from the parallel-vm.py processing
and instead, simply requeues the failed test cases into the same queue
that is used for the initial run. This is simpler and more efficient
since reruns start as soon as any VM is ready for processing them
instead of having to wait for all VMs to complete the first round.
Furthermore, this allows VMs to be stopped sooner when no more test
cases remain and that is helpful especially with the time travel patches
that make the wait-for-next-test step in the VM use all available CPU.
Signed-off-by: Jouni Malinen <j@w1.fi>
Print a list of full paths to log files from failed test cases both the
parallel.log and stdout so that they can be easily opened for analysis.
In addition, renumber the VM lines in the <timestamp>-parallel.log to
match the i+1 numbering used in the log directories and UI that is
tracking test execution.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This allows unexpected cases to terminate parallel-vm.py without being
hidden by the exception handler.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
The result of reading non blocked empty stream is different between
python2 and 3. The python2 sends "[Errno 11] Resource temporarily
unavailable" exception. The python3 could read "None" without
exception, so handle this "None" case as well.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
If telnetd is installed and --telnet <port> is passed on the
vm-run.sh command line, start a telnet server (directly connected
to bash, no login) inside the VM(s) to be able to look into them
when something is wrong. Use a user network in qemu with a single
host forward from the specified port for this, listening only on
'localhost'.
Please note that this provides unauthenticated access to the guest
system from anything that can open a TCP connection on the host system.
The guess system does have access to reading all files on the host that
the user account running kvm has access to (and even write access if the
default ROTAG ,readonly parameter is cleared). In other words, this
option should not be used on any multiuser systems where kvm is run
under user accounts that are not dedicated for testing purposes (i.e.,
do not have access to any files that should not be readable to
everyone).
This needs CONFIG_VIRTIO_NET=y in the guest kernel.
For parallel-vm.py, the --telnet argument specifies the base port
and each VM index (0, 1, ...) is added to it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is useful for now since the IPv6 support for proxyarp is not yet
included in the upstream kernel. This allows the IPv4 test cases to pass
with the current upstream kernel while allowing the IPv6 test cases to
report SKIP instead of FAIL.
Signed-off-by: Jouni Malinen <j@w1.fi>
Now that vm-run.sh supports a long list of test cases without crashing
the VM kernel, there is no need to use the "parallel-vm.py -1 1 <tests>"
workaround. Print the re-run example commands with vm-run.sh instead. In
addition, add the --long argument if it was specified for the test run
to avoid skipping test cases in the re-run case.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If /tmp has a relatively small size limit, or multiple people run the
tests on the same machine, using the same output directory can easily
cause problems.
Make the test framework honor the new HWSIM_TEST_LOG_DIR environment
variable to make it easier to avoid those problems.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It looks like it was possible to receive an incomplete FAIL line and
break out from test execution due to a parsing error. Handle this more
robustly and log the error.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The 'params' argument was not used at all. Use it as an alternative
means for setting the list of test cases to execute.
Signed-off-by: Jouni Malinen <j@w1.fi>
This can be used to filter out test cases that take significantly longer
time to execute (15 seconds or longer). While this reduces testing
coverage, this can be useful to get a pretty quick coverage in
significantly faster time.
Signed-off-by: Jouni Malinen <j@w1.fi>
It's somewhat annoying that you can only run parallel-vm.py as
./parallel-vm.py, not from elsewhere by giving the full path,
so fix that by resolving the paths correctly in the scripts where
needed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of hand-writing a (positional) parser, use the argparse module.
This also gets us nice help output.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It was possible for the scr.addstr() operations to fail and terminate
parallel-vm.py if the number of failed test cases increased beyond what
fits on the screen.
Signed-off-by: Jouni Malinen <j@w1.fi>
Merge partial lines together before processing them in parallel-vm.py.
This avoids issues in cases where the stdout read gets split into pieces
that do not include the full READY/PASS/FAIL/SKIP information. In
addition, strip unnecessary whitespace (mainly, '\r') from the log
lines.
Signed-off-by: Jouni Malinen <j@w1.fi>
parallel-vm.log is now written with details of test execution steps and
results. This makes it easier to debug if something goes wrong in VM
monitoring. The --debug option can be used to enable verbose debugging.
Signed-off-by: Jouni Malinen <j@w1.fi>
parallel-vm.py is now retrying failed cases once at the end of the run.
If all the failed test cases passed on the second attempt, that is noted
in the summary output. Results are also indicated as the exit value from
the run: 0 = all cases passed on first run, 1 = some cases failed once,
but everything passed after one retry, 2 = some cases failed did not
succeed at all.
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds the remaining test cases that took more than 15 seconds to run
into the list of test cases to run at the beginning of the execution to
avoid these being left at the end when only some of the VMs may be
running.
Signed-off-by: Jouni Malinen <j@w1.fi>
These test cases had a long 120 seconds wait for the GO Negotiation
initiator to time out. This can be done using two devices in parallel to
save two minutes from total test execution time.
Signed-off-by: Jouni Malinen <j@w1.fi>
Wait one second between each kvm start to avoid hitting large number of
processes trying to start in parallel. This allows the VMs to be started
more efficiently for parallel-vm.py runs with large number of VMs.
Signed-off-by: Jouni Malinen <j@w1.fi>
Move test cases with long duration to the beginning as an optimization
to avoid last part of the test execution running a long duration test
case on a single VM while all other VMs have already completed their
work.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows code coverage report to be generated must faster with the
help of parallel VMs executing test cases.
Signed-off-by: Jouni Malinen <j@w1.fi>
There is no need to pass the test case names to the VMs when using
parallel-vm.py. Removing those from the command line helps in avoiding
kernel panic if maximum number of kernel parameters limit is hit.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows all VMs to be used at the end of a test sequence by
assigning test cases to VMs based on which VM is available for a new
test case rather than splitting the full task at the beginning and
potentially getting stuck with the last VM running long test cases for
significantly longer than another VM that gets shorter duration tests
assigned to it.
Signed-off-by: Jouni Malinen <j@w1.fi>
Previously, it was possible for a kernel panic to be missed since the
only sign of it in stdout was reduced number of passed test cases.
Signed-off-by: Jouni Malinen <j@w1.fi>
This avoids possible mismatches in directory and log file timestamps if
the UNIX timestamp (seconds) changes during the startup sequence.
Signed-off-by: Jouni Malinen <j@w1.fi>
