On 11/23/20 2:45 PM, Christian Schoenebeck wrote: > On Montag, 23. November 2020 14:48:15 CET Christian Schoenebeck wrote: >> On Montag, 23. November 2020 14:17:34 CET Greg Kurz wrote: >>> Fixed maintainer's address: s/o...@crudebyte.com/qemu_...@crudebyte.com >>> >>> On Sat, 21 Nov 2020 17:03:14 -0500 >>> >>> Cole Robinson <crobi...@redhat.com> wrote: >>>> Hi, I'm consistently seeing this assertion running the qemu-5.2.0 test >>>> suite. rc0, rc1, rc2 have been consistently affected, it reproduces >>>> consistently in parts of Fedora's build system. Here's an example build >>>> log for rc2 x86 against Fedora 32 >>>> >>>> https://download.copr.fedorainfracloud.org/results/@kubevirt/qemu-5.2.0-> >>>> > > 0. >>>> 6.rc2/fedora-32-x86_64/01781514-qemu/builder-live.log.gz >>>> >>>> The full test error: >>>> >>>> ... >>>> PASS 26 qtest-arm/qos-test >>>> /arm/virt/virtio-mmio/virtio-bus/virtio-9p-device/virtio-9p/virtio-9p-te >>>> st >>>> s/synth/readdir/split_128 PASS 27 qtest-arm/qos-test >>>> /arm/virt/virtio-mmio/virtio-bus/virtio-9p-device/virtio-9p/virtio-9p-te >>>> st >>>> s/local/config >>> >>> Ok so the next test is supposed to be: >>> >>> /arm/virt/virtio-mmio/virtio-bus/virtio-9p-device/virtio-9p/virtio-9p-test >>> s/ local/create_dir >>> >>> This was added recently. This configures the virtio-9p device in QEMU >>> to serve a real test directory from the host. This test directory is >>> created under the current directory of the test process. The purpose >>> of the test is then to ask the 9p server to create a directory within >>> the test directory. >>> >>>> Received response 7 (RLERROR) instead of 73 (RMKDIR) >>>> ERROR qtest-arm/qos-test - Bail out! >>>> ERROR:../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion >>>> failed (hdr.id == id): (7 == 73) >>>> Rlerror has errno 95 (Operation not supported) >>> >>> So this basically means that QEMU got ENOTSUP/EOPNOTSUPP when calling >>> mkdir() into the test directory... not sure what could cause that. I'd >>> need more details on the filesystem setup for the build. >>> >>> Anyway, we already experienced some breakage in upstream CI because of >>> the same family of tests that do real access to the host filesystem. >>> Since they're being introduced in QEMU 5.2, I'll try to see if I can >>> disable them to be run by default for RC3. >>> >>> Cheers, >>> >>> -- >>> Greg >>> >>>> ** >>>> ERROR:../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion >>>> failed (hdr.id == id): (7 == 73) >>>> make: *** [Makefile.mtest:1257: run-test-155] Error 1 >>>> error: Bad exit status from /var/tmp/rpm-tmp.EG4Dav (%check) >>>> >>>> >>>> Thanks, >>>> Cole >> >> Yeah, looks like the mkdir() call which is supposed to create the 9p test >> directory, is failing there for some reason. The question is how to find >> that out (effectively) without having access to an affected system. >> >> It's now too late for 5.2, but I think for 6.0 it would make sense >> introducing a dedicated 9p option loglevel=..., so we can tell people to >> enable this to capture the precise source location where an error ocurred. >> That would mean spreading a huge bunch of macros all over the 9p code base, >> but it would definitely help a lot understanding the root cause of reported >> issues in an efficient way. >> >> Best regards, >> Christian Schoenebeck > > Cole, does the affected host system probably not have xattrs enabled on its > file system? >
Hmm I'm not sure, I will try to investigate. google tells me David Gilbert also hit this too earlier: https://www.mail-archive.com/qemu-devel@nongnu.org/msg754556.html Maybe he remembers details of his setup, CC'd - Cole
