Running repeated invocations on a number of test boxes show a fairly
high error rate:
$ retry.py -n 100 -c -- ./tests/venv/bin/avocado run tests/avocado/boot_linux_console.py:BootLinuxConsole.test_sh4_r2d
retry.py called with ['./tests/venv/bin/avocado', 'run', 'tests/avocado/boot_linux_console.py:BootLinuxConsole.test_sh4_r2d']
Results:
Run, Ret, Pass/Fail, Time, Total Pass, Total Run
...
Results summary:
0: 94 times (94.00%), avg time 2.254 (0.00 varience/0.04 deviation)
1: 3 times (3.00%), avg time 1.837 (0.02 varience/0.14 deviation)
8: 3 times (3.00%), avg time 91.288 (0.02 varience/0.15 deviation)
Examining the logs they fall into various categories of un-handled
unaligned access by user space and unexpected FPU usage by the kernel
which ultimately lead to the failure to reach the login prompt. This
could be bugs in the translator that only get hit occasionally or just
a flaky kernel - its hard to tell. To avoid these failures gating CI
lets skip on GitLab.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Thomas Huth <thuth@redhat.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Magnus Damm <magnus.damm@gmail.com>
Message-Id: <20221027183637.2772968-21-alex.bennee@linaro.org>
The avocado test
tests/avocado/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd
finishes with
exec_command(self, 'halt')
# Wait for VM to shut down gracefully
self.vm.wait()
In theory this should be fine. In practice it runs into two bugs:
* when the test calls self.vm.wait() Avocado closes the socket
connection to the guest serial console immediately, so the
avocado logs don't have the last part of the guest output:
https://gitlab.com/qemu-project/qemu/-/issues/1265
* when the socket is closed, a bug in the QEMU socket chardev
means that it loses any data that the guest UART has not
yet consumed. This means that the guest doesn't always read
the full 'halt' command string, so the test intermittently
fails with a timeout:
https://gitlab.com/qemu-project/qemu/-/issues/1264
Work around both of these by waiting for the guest to print the
string that means it has completed the shutdown process. This fixes
a very long standing intermittent failure in this test.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/636
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20221020102012.3015662-1-peter.maydell@linaro.org>
Message-Id: <20221027183637.2772968-20-alex.bennee@linaro.org>
Some avocado tests fail if QEMU was built without libslirp. Add
require_netdev('user') checks where necessary:
These tests try to ping 10.0.2.2 and expect it to succeed:
boot_linux_console.py:BootLinuxConsole.test_arm_emcraft_sf2
boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_sd
ppc_bamboo.py:BambooMachine.test_ppc_bamboo
These tests run a commandline that includes '-net user':
machine_aspeed.py:AST2x00Machine.test_arm_ast2500_evb_builroot
(and others that use the do_test_arm_aspeed_buidroot_start()
or do_test_arm_aspeed_sdk_start() helper functions)
These changes seem to be sufficient for 'make check-avocado'
to not fail on a --disable-slirp build.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20221001195224.2453581-1-peter.maydell@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The assets that this test tries to download have been removed from the
server. Update to a newer version to get it working again.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20220829080940.110831-1-thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20220914155950.804707-3-alex.bennee@linaro.org>
It's easier to run. Keep test_arm_ast2600_debian() under the
boot_linux_console.py file because it requires the extract_from_deb()
helper. We could remove it when we have tests for the AST2600.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The Fedora 29 kernel is quite old and importantly fails when running
in LPA2 scenarios. As it's not really exercising much of the CPU space
replace it with a custom 5.16.12 kernel with all the architecture
options turned on. There is a minimal buildroot initramfs included in
the kernel which has a few tools for stress testing the memory
subsystem. The userspace also targets the Neoverse N1 processor so
would fail with a v8.0 cpu like cortex-a53.
While we are at it move the test into its own file so it can have an
assigned maintainer.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Acked-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220419091020.3008144-2-alex.bennee@linaro.org>
This test breaks when run in an IBM POWER host with a QEMU compiled
with --disable-tcg and the ppc-softmmu target in a similar manner as
test_ppc_g3beige did.
There's also an observation made about kvm_pr in the error message:
Command: ./qemu-system-ppc -display none -vga none (...)
-machine mac99 (...)
Output: ioctl(KVM_CREATE_VM) failed: 22 Invalid argument
PPC KVM module is not loaded. Try modprobe kvm_pr.
qemu-system-ppc: failed to initialize kvm: Invalid argument
This means that, when/if we're able to detect kvm_pr support in these
avocado tests, we can revisit this test to not rely solely on TCG
availability.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220310183011.110391-3-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
This test breaks when run in an IBM POWER host with a QEMU compiled
with --disable-tcg and the ppc-softmmu target.
One thing to note is that the error message explictly mentions kvm_pr
support:
Command: ./qemu-system-ppc -display none -vga none (...)
-machine g3beige (...)
Output: ioctl(KVM_CREATE_VM) failed: 22 Invalid argument
PPC KVM module is not loaded. Try modprobe kvm_pr.
qemu-system-ppc: failed to initialize kvm: Invalid argument
The host was running kvm_hv, not kvm_pr, and the machine failed to load.
Unfortunately we don't have a way to detect whether the KVM module loaded
is kvm_hv or kvm_pr - we do a check for /dev/kvm to detect KVM support but
both modules create this file so that's not helpful.
Let's skip this test for now until we have a way of detecting kvm_pr support in the host.
Reported-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220310183011.110391-2-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Some ppc64 hosts (e.g. IBM POWER hosts) aren't able to run the e500
machine using KVM accel. Skip this test if TCG accel isn't available.
Cc: Cleber Rosa <crosa@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220303153517.168943-5-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The PowerNV8/9 machines does not work with KVM acceleration, meaning
that boot_linux_console.py:BootLinuxConsole.test_ppc_powernv8/9 tests
will always fail when QEMU is compiled with --disable-tcg:
ERROR 1-tests/avocado/boot_linux_console.py:BootLinuxConsole.test_ppc_powernv8
-> VMLaunchFailure: ConnectError: Failed to establish session:
[Errno 104] Connection reset by peer
Exit code: 1
Command: ./qemu-system-ppc64 -display none -vga none -chardev socket,id=mon,path=/var/tmp/avo_qemu_sock_no19zg0m/qemu-1936936-7fffa77cff98-monitor.sock -mon chardev=mon,mode=control -machine powernv8 -chardev socket,id=console,path=/var/tmp/avo_qemu_sock_no19zg0m/qemu-1936936-7fffa77cff98-console.sock,server=on,wait=off -serial chardev:console -kernel /home/danielhb/avocado/data/cache/by_location/4514304e2c4ee84c5f0b5c8bacedda783891df68/zImage.epapr -append console=tty0 console=hvc0 -device pcie-pci-bridge,id=bridge1,bus=pcie.1,addr=0x0 -device nvme,bus=pcie.2,addr=0x0,serial=1234 -device e1000e,bus=bridge1,addr=0x3 -device nec-usb-xhci,bus=bridge1,addr=0x2
Output: qemu-system-ppc64: The powernv machine does not work with KVM acceleration
Let's add the TCG accel requirement in both tests to skip them if we
don't have TCG support available.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220303153517.168943-4-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The single use of the 7z binary has been removed in commit a30e114f3
("tests/acceptance: remove Armbian 19.11.3 test for orangepi-pc"),
we don't need to check for this binary availability anymore.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Joaquin de Andres <me@xcancerberox.com.ar>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Message-Id: <20211106091059.465109-1-philmd@redhat.com>
To run user-mode emulation tests, we introduced the
avocado_qemu.QemuUserTest which inherits from avocado_qemu.QemuBaseTest.
System-mode emulation tests are based on the avocado_qemu.Test class,
which also inherits avocado_qemu.QemuBaseTest. To avoid confusion,
rename it as avocado_qemu.QemuSystemTest.
Suggested-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211105143416.148332-7-f4bug@amsat.org>
In the discussion about renaming the `tests/acceptance` [1], the
conclusion was that the folders inside `tests` are related to the
framework running the tests and not directly related to the type of
the tests.
This changes the folder to `tests/avocado` and adjusts the MAKEFILE, the
CI related files and the documentation.
[1] https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg06553.html
Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Willian Rampazzo <willianr@redhat.com>
Message-Id: <20211105155354.154864-3-willianr@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
