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.
The test that fails seems to be the same, just the errno is different in your
case.
Best regards,
Christian Schoenebeck
