On 25/03/2024 14.25, Christian Schoenebeck wrote:
On Monday, March 25, 2024 1:35:52 PM CET Daniel Henrique Barboza wrote:
On 3/25/24 06:20, Thomas Huth wrote:
On 08/03/2024 12.11, Alistair Francis wrote:
From: Daniel Henrique Barboza <dbarb...@ventanamicro.com>

Add a RISC-V 'virt' machine to the graph. This implementation is a
modified copy of the existing arm machine in arm-virt-machine.c

It contains a virtio-mmio and a generic-pcihost controller. The
generic-pcihost controller hardcodes assumptions from the ARM 'virt'
machine, like ecam and pio_base addresses, so we'll add an extra step to
set its parameters after creating it.

Our command line is incremented with 'aclint' parameters to allow the
machine to run MSI tests.

Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Acked-by: Alistair Francis <alistair.fran...@wdc.com>
Acked-by: Thomas Huth <th...@redhat.com>
Message-ID: <20240217192607.32565-7-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
---

   Hi!

I noticed that "make check SPEED=slow" is now failing on the qos-test with 
both, qemu-system-riscv32 and qemu-system-riscv64. Seems like it fails with the virtio-9p 
test, when I run the qos-test manually, I get:

$ MALLOC_PERTURB_=21 V=2 QTEST_QEMU_BINARY=./qemu-system-riscv64 \
     tests/qtest/qos-test -m slow
...
# Start of local tests
# starting QEMU: exec ./qemu-system-riscv64 -qtest unix:/tmp/qtest-211303.sock 
-qtest-log /dev/null -chardev socket,path=/tmp/qtest-211303.qmp,id=char0 -mon 
chardev=char0,mode=control -display none -audio none -M 
virt,aclint=on,aia=aplic-imsic -fsdev 
local,id=fsdev0,path='/home/thuth/tmp/qemu-build/qtest-9p-local-MBCML2',security_model=mapped-xattr
 -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest
ok 168 
/riscv64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config
Received response 7 (RLERROR) instead of 73 (RMKDIR)
Rlerror has errno 17 (File exists)
**
ERROR:../../devel/qemu/tests/qtest/libqos/virtio-9p-client.c:275:v9fs_req_recv: 
assertion failed (hdr.id == id): (7 == 73)
not ok 
/riscv64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/create_dir
 - 
ERROR:../../devel/qemu/tests/qtest/libqos/virtio-9p-client.c:275:v9fs_req_recv: 
assertion failed (hdr.id == id): (7 == 73)
Bail out!
Aborted (core dumped)

Could you please have a look? ... or if it is too cumbersome to fix, could we 
please always skip the virtio-9p local tests on riscv ?

I'll take a look.

Do we run these slow tests in the Gitlab pipeline? I don't recall this
particular test failing when I first introduced the riscv machine nodes.

No, the 'local' 9p tests were taken out by moving them to 'slow', because
these particular tests did not pass in the cloud and gitlab doesn't run
'slow':

commit 558f5c42efded3e0d0b20a90bce2a9a14580d824
Author: Greg Kurz <gr...@kaod.org>
Date:   Tue Nov 24 08:43:43 2020 +0100

     tests/9pfs: Mark "local" tests as "slow"
The "local" tests can fail on some automated build systems as
     reported here:
https://lists.nongnu.org/archive/html/qemu-devel/2020-11/msg05510.html This will need to be investigated and addressed later. Let's go for a
     workaround in the meantime : mark the "local" tests as "slow" so that
     they aren't executed with a simple "make check" like in the case above.
Reported-by: Cole Robinson <crobi...@redhat.com>
     Signed-off-by: Greg Kurz <gr...@kaod.org>
     Reviewed-by: Thomas Huth <th...@redhat.com>
     Acked-by: Christian Schoenebeck <qemu_...@crudebyte.com>
     Message-Id: <160620382310.1423262.7364287092069513483.st...@bahia.lan>
     Signed-off-by: Greg Kurz <gr...@kaod.org>

Could be because the 'local' 9p backend needs xattr support which might not be
available with gitlab container's filesystem. But I haven't investigated.

I just ran "make check SPEED=slow" locally on my laptop. Only the riscv qos-tests were failing, the other targets worked fine. So this must be something specific to riscv, I think.

 Thomas


Reply via email to