Hi Christian, On 7/3/2026 7:36 AM, Christian Schoenebeck wrote: > On Thursday, 2 July 2026 20:21:54 CEST Pierrick Bouvier wrote: >> Hi Christian, >> >> On 7/1/2026 9:20 AM, Christian Schoenebeck wrote: >>> On Tuesday, 30 June 2026 09:28:48 CEST Pierrick Bouvier wrote: >>>> Hi Christian, >>> >>> Hi Pierrick, >>> >>>> This series brought a test regression: >>>> $ ./build/pyvenv/bin/meson test -C build \ >>>> --setup thorough --print-errorlogs \ >>>> qemu:qtest-aarch64/qos-test >>>> ... >>>> ERROR:../tests/qtest/libqos/virtio-9p-client.c:280:v9fs_req_recv: >>>> assertion failed (hdr.id == id): (7 == 121) >>>> >>>> It seems to come test added in patch 19 >>>> "tests/9p: add 3 xattr FID limit test cases (synth fs driver)" >>>> This test runs only with slow setup, so I suspect it never worked and >>>> was never ran. >>> >>> Of course I ran these slow tests. >> >> I should have added "in our CI" sorry. I'm sure you developed, tested >> and ran those yourself. >> >>> I intentionally registered these tests as "slow" tests as they take a long >>> time to complete and QEMU tests being notorious on exceeding the overall >>> CI >>> timeout limit. So these tests are exempted from running in the official CI >>> pipeline, but not from mine. >>> >>> I just reran them with latest master head. However I am unable to >>> reproduce >>> your reported test error so far. >>> >>> You cropped the output too aggressively. I need to know: >>> >>> - Which test exactly failed? (especially whether it's really a synth >>> backend> >>> or a local backend test that failed) >> >> That's the complete log from the command given above. >> Note: disk is not full, but the error "no space left on device" is very >> weird. > > OK, I was able to reproduce the test error. Root cause is that ext4 without > ea_inode enabled is limited to ~4KB per xattr block. I'll prepare a patch. >
Just saw it, I'll test and review it. Thanks! > For the next time: please note that the most important information is always > the name of the test case that failed! There are several ways to run the > tests. In the way you ran them, the name of the failed test is printed > *before* the stderr block: > > ... > # slow test /aarch64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p- > pci/virtio-9p/virtio-9p-tests/local/deep_absolute_path executed in 1.63 secs > # Start of xattr_limit tests > # starting QEMU: exec ./qemu-system-aarch64 -qtest unix:/tmp/qtest-22413.sock > -qtest-log /dev/null -chardev socket,path=/tmp/qtest-22413.qmp,id=char0 -mo > n chardev=char0,mode=control -display none -audio none -run-with exit-with- > parent=on -M virt, -cpu max -fsdev local,id=fsdev0,path='/src/bee/qemu/build/q > test-9p-local-KKOMR3',security_model=mapped-xattr -device virtio-9p- > pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest > not ok /aarch64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p-pci/ > virtio-9p/virtio-9p-tests/local/xattr_limit/default - ERROR:../tests/qtest/lib > qos/virtio-9p-client.c:280:v9fs_req_recv: assertion failed (hdr.id == id): (7 > == 121) > Bail out! > ----------------------------------- stderr ----------------------------------- > ... > > So here the failing test name was /aarch64/virt/generic-pcihost/pci-bus- > generic/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/xattr_limit/ > default > > Independent of this particular issue here, I wonder whether there is some way > to register a test such that it won't break other people's test pipeline. > Because these "local" backend xattr tests are sensible on underlying host > capabilities. They are useful for me, but that should not mean to stop the > world just because an unrelated test environment is missing a capability. > There is no mechanism to attach a criteria to run a test. In this case, the only solution would be to check this attribute at runtime (in the test itself), and return 0 to indicate success. IMHO, that's a perfectly valid strategy. Also, it has the benefit to keep all the information in the test itself, instead of spreading it across multiple files. Functional tests are a bit more evolved and offer some skip possibilities, and I'm not sure it's worth extending this to other tests. > /Christian > > > > Thanks, Pierrick.
