| Message ID | cover.1603452058.git.qemu_oss@crudebyte.com |
|---|---|
| State | New |
| Headers | show |
On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > > The following changes since commit 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430: > > Merge remote-tracking branch 'remotes/kraxel/tags/modules-20201022-pull-request' into staging (2020-10-22 12:33:21 +0100) > > are available in the Git repository at: > > https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023 > > for you to fetch changes up to ee01926a11b1f9bffcd6cdec0961dd9d1882da71: > > tests/9pfs: add local Tunlinkat hard link test (2020-10-22 20:26:33 +0200) > > ---------------------------------------------------------------- > 9pfs: more tests using local fs driver > > Only 9pfs test case changes this time: > > * Refactor: Rename functions to make top-level test functions fs_*() > easily distinguishable from utility test functions do_*(). > > * Refactor: Drop unnecessary function arguments in utility test > functions. > > * More test cases using the 9pfs 'local' filesystem driver backend, > namely for the following 9p requests: Tunlinkat, Tlcreate, Tsymlink > and Tlink. > > ---------------------------------------------------------------- I get a 'make check' failure on x86-64 Linux host: PASS 54 qtest-x86_64: qos-test /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config PASS 55 qtest-x86_64: qos-test /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/symlink_file Received response 7 (RLERROR) instead of 73 (RMKDIR) Rlerror has errno 2 (No such file or directory) ** ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion failed (hdr.id == id): (7 == 73) ERROR qtest-x86_64: qos-test - Bail out! ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion failed (hdr.id == id): (7 == 73) Makefile.mtest:3953: recipe for target 'run-test-492' failed thanks -- PMM
On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote: > On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck > > <qemu_oss@crudebyte.com> wrote: > > The following changes since commit 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430: > > Merge remote-tracking branch > > 'remotes/kraxel/tags/modules-20201022-pull-request' into staging > > (2020-10-22 12:33:21 +0100)> > > are available in the Git repository at: > > https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023 > > > > for you to fetch changes up to ee01926a11b1f9bffcd6cdec0961dd9d1882da71: > > tests/9pfs: add local Tunlinkat hard link test (2020-10-22 20:26:33 > > +0200) > > > > ---------------------------------------------------------------- > > 9pfs: more tests using local fs driver > > > > Only 9pfs test case changes this time: > > > > * Refactor: Rename functions to make top-level test functions fs_*() > > > > easily distinguishable from utility test functions do_*(). > > > > * Refactor: Drop unnecessary function arguments in utility test > > > > functions. > > > > * More test cases using the 9pfs 'local' filesystem driver backend, > > > > namely for the following 9p requests: Tunlinkat, Tlcreate, Tsymlink > > and Tlink. > > > > ---------------------------------------------------------------- > > I get a 'make check' failure on x86-64 Linux host: > > PASS 54 qtest-x86_64: qos-test > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > 9p-tests/local/config PASS 55 qtest-x86_64: qos-test > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > 9p-tests/local/symlink_file Received response 7 (RLERROR) instead of 73 > (RMKDIR) > Rlerror has errno 2 (No such file or directory) > ** > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion > failed (hdr.id == id): (7 == 73) > ERROR qtest-x86_64: qos-test - Bail out! > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion > failed (hdr.id == id): (7 == 73) > Makefile.mtest:3953: recipe for target 'run-test-492' failed > > > thanks > -- PMM So the 9p server is already failing to create the test case directory "./qtest-9p-local/05/" relative to your current working directory. I would appreciate to get more info when you have some free cycles, as I'm unable to reproduce this on any system unfortunately. But no hurry as these tests only become relevant actually for QEMU 6. What puzzles me is that the previous test cases succeeded there, which all create their own test directory in the same way: ./qtest-9p-local/01/ ./qtest-9p-local/02/ (<-- dir vanishes after that test completed) ./qtest-9p-local/03/ ./qtest-9p-local/04/ ... How does the "./qtest-9p-local/" directory look like after that "local/symlink_file" test failed there? You can use this shortcut: export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 cd build tests/qtest/qos-test --verbose ls -l qtest-9p-local That latter qos-test run will also output the assembled qemu command line the 9p local tests would run with, which might also be helpful, e.g. the relevant output would be something like this: GTest: run: /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config (MSG: starting QEMU: exec x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-7428.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-7428.qmp,id=char0 -mon chardev=char0,mode=control -display none -M pc -fsdev local,id=fsdev0,path='/home/me/git/qemu/build/qtest-9p-local',security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest) Would probably the test succeed if run alone? tests/qtest/qos-test -p /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/symlink_file Best regards, Christian Schoenebeck
On Mon, 26 Oct 2020 13:48:37 +0100 Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote: > > On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck > > > > <qemu_oss@crudebyte.com> wrote: > > > The following changes since commit 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430: > > > Merge remote-tracking branch > > > 'remotes/kraxel/tags/modules-20201022-pull-request' into staging > > > (2020-10-22 12:33:21 +0100)> > > > are available in the Git repository at: > > > https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023 > > > > > > for you to fetch changes up to ee01926a11b1f9bffcd6cdec0961dd9d1882da71: > > > tests/9pfs: add local Tunlinkat hard link test (2020-10-22 20:26:33 > > > +0200) > > > > > > ---------------------------------------------------------------- > > > 9pfs: more tests using local fs driver > > > > > > Only 9pfs test case changes this time: > > > > > > * Refactor: Rename functions to make top-level test functions fs_*() > > > > > > easily distinguishable from utility test functions do_*(). > > > > > > * Refactor: Drop unnecessary function arguments in utility test > > > > > > functions. > > > > > > * More test cases using the 9pfs 'local' filesystem driver backend, > > > > > > namely for the following 9p requests: Tunlinkat, Tlcreate, Tsymlink > > > and Tlink. > > > > > > ---------------------------------------------------------------- > > > > I get a 'make check' failure on x86-64 Linux host: > > > > PASS 54 qtest-x86_64: qos-test > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > 9p-tests/local/config PASS 55 qtest-x86_64: qos-test > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > 9p-tests/local/symlink_file Received response 7 (RLERROR) instead of 73 > > (RMKDIR) > > Rlerror has errno 2 (No such file or directory) > > ** > > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion > > failed (hdr.id == id): (7 == 73) Not sure this is related to this PR actually. Dave Gilbert reported on irc that he encountered a similar issue with 'make -j check', likely without these patches. > > ERROR qtest-x86_64: qos-test - Bail out! > > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion > > failed (hdr.id == id): (7 == 73) > > Makefile.mtest:3953: recipe for target 'run-test-492' failed > > > > > > thanks > > -- PMM > > So the 9p server is already failing to create the test case directory > "./qtest-9p-local/05/" relative to your current working directory. > > I would appreciate to get more info when you have some free cycles, as I'm > unable to reproduce this on any system unfortunately. But no hurry as > these tests only become relevant actually for QEMU 6. > > What puzzles me is that the previous test cases succeeded there, which all > create their own test directory in the same way: > > ./qtest-9p-local/01/ > ./qtest-9p-local/02/ (<-- dir vanishes after that test completed) > ./qtest-9p-local/03/ > ./qtest-9p-local/04/ > ... > > How does the "./qtest-9p-local/" directory look like after that > "local/symlink_file" test failed there? You can use this shortcut: > > export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 > cd build > tests/qtest/qos-test --verbose > ls -l qtest-9p-local > > That latter qos-test run will also output the assembled qemu command > line the 9p local tests would run with, which might also be helpful, > e.g. the relevant output would be something like this: > > GTest: run: /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config > (MSG: starting QEMU: exec x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-7428.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-7428.qmp,id=char0 -mon chardev=char0,mode=control -display none -M pc -fsdev local,id=fsdev0,path='/home/me/git/qemu/build/qtest-9p-local',security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest) > > Would probably the test succeed if run alone? > > tests/qtest/qos-test -p /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/symlink_file > > Best regards, > Christian Schoenebeck > >
* Greg Kurz (groug@kaod.org) wrote: > On Mon, 26 Oct 2020 13:48:37 +0100 > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > > > On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote: > > > On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck > > > > > > <qemu_oss@crudebyte.com> wrote: > > > > The following changes since commit 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430: > > > > Merge remote-tracking branch > > > > 'remotes/kraxel/tags/modules-20201022-pull-request' into staging > > > > (2020-10-22 12:33:21 +0100)> > > > > are available in the Git repository at: > > > > https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023 > > > > > > > > for you to fetch changes up to ee01926a11b1f9bffcd6cdec0961dd9d1882da71: > > > > tests/9pfs: add local Tunlinkat hard link test (2020-10-22 20:26:33 > > > > +0200) > > > > > > > > ---------------------------------------------------------------- > > > > 9pfs: more tests using local fs driver > > > > > > > > Only 9pfs test case changes this time: > > > > > > > > * Refactor: Rename functions to make top-level test functions fs_*() > > > > > > > > easily distinguishable from utility test functions do_*(). > > > > > > > > * Refactor: Drop unnecessary function arguments in utility test > > > > > > > > functions. > > > > > > > > * More test cases using the 9pfs 'local' filesystem driver backend, > > > > > > > > namely for the following 9p requests: Tunlinkat, Tlcreate, Tsymlink > > > > and Tlink. > > > > > > > > ---------------------------------------------------------------- > > > > > > I get a 'make check' failure on x86-64 Linux host: > > > > > > PASS 54 qtest-x86_64: qos-test > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > > 9p-tests/local/config PASS 55 qtest-x86_64: qos-test > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > > 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > > 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > > 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > > 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > > 9p-tests/local/symlink_file Received response 7 (RLERROR) instead of 73 > > > (RMKDIR) > > > Rlerror has errno 2 (No such file or directory) > > > ** > > > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion > > > failed (hdr.id == id): (7 == 73) > > Not sure this is related to this PR actually. Dave Gilbert reported on irc that > he encountered a similar issue with 'make -j check', likely without these patches. I was running on current master as of yesterday; no 9p specific patches. Dave > > > ERROR qtest-x86_64: qos-test - Bail out! > > > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion > > > failed (hdr.id == id): (7 == 73) > > > Makefile.mtest:3953: recipe for target 'run-test-492' failed > > > > > > > > > thanks > > > -- PMM > > > > So the 9p server is already failing to create the test case directory > > "./qtest-9p-local/05/" relative to your current working directory. > > > > I would appreciate to get more info when you have some free cycles, as I'm > > unable to reproduce this on any system unfortunately. But no hurry as > > these tests only become relevant actually for QEMU 6. > > > > What puzzles me is that the previous test cases succeeded there, which all > > create their own test directory in the same way: > > > > ./qtest-9p-local/01/ > > ./qtest-9p-local/02/ (<-- dir vanishes after that test completed) > > ./qtest-9p-local/03/ > > ./qtest-9p-local/04/ > > ... > > > > How does the "./qtest-9p-local/" directory look like after that > > "local/symlink_file" test failed there? You can use this shortcut: > > > > export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 > > cd build > > tests/qtest/qos-test --verbose > > ls -l qtest-9p-local > > > > That latter qos-test run will also output the assembled qemu command > > line the 9p local tests would run with, which might also be helpful, > > e.g. the relevant output would be something like this: > > > > GTest: run: /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config > > (MSG: starting QEMU: exec x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-7428.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-7428.qmp,id=char0 -mon chardev=char0,mode=control -display none -M pc -fsdev local,id=fsdev0,path='/home/me/git/qemu/build/qtest-9p-local',security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest) > > > > Would probably the test succeed if run alone? > > > > tests/qtest/qos-test -p /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/symlink_file > > > > Best regards, > > Christian Schoenebeck > > > > >
On Dienstag, 27. Oktober 2020 10:06:53 CET Dr. David Alan Gilbert wrote: > * Greg Kurz (groug@kaod.org) wrote: > > On Mon, 26 Oct 2020 13:48:37 +0100 > > > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > > > On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote: > > > > On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck > > > > > > > > <qemu_oss@crudebyte.com> wrote: > > > > > The following changes since commit 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430: > > > > > Merge remote-tracking branch > > > > > 'remotes/kraxel/tags/modules-20201022-pull-request' into staging > > > > > (2020-10-22 12:33:21 +0100)> > > > > > > > > > > are available in the Git repository at: > > > > > https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023 > > > > > > > > > > for you to fetch changes up to ee01926a11b1f9bffcd6cdec0961dd9d1882da71: > > > > > tests/9pfs: add local Tunlinkat hard link test (2020-10-22 > > > > > 20:26:33 > > > > > +0200) > > > > > > > > > > ---------------------------------------------------------------- > > > > > 9pfs: more tests using local fs driver > > > > > > > > > > Only 9pfs test case changes this time: > > > > > > > > > > * Refactor: Rename functions to make top-level test functions fs_*() > > > > > > > > > > easily distinguishable from utility test functions do_*(). > > > > > > > > > > * Refactor: Drop unnecessary function arguments in utility test > > > > > > > > > > functions. > > > > > > > > > > * More test cases using the 9pfs 'local' filesystem driver backend, > > > > > > > > > > namely for the following 9p requests: Tunlinkat, Tlcreate, > > > > > Tsymlink > > > > > and Tlink. > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > > I get a 'make check' failure on x86-64 Linux host: > > > > > > > > PASS 54 qtest-x86_64: qos-test > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v > > > > irtio- 9p-tests/local/config PASS 55 qtest-x86_64: qos-test > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v > > > > irtio- 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v > > > > irtio- 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v > > > > irtio- 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v > > > > irtio- 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v > > > > irtio- 9p-tests/local/symlink_file Received response 7 (RLERROR) > > > > instead of 73 (RMKDIR) > > > > Rlerror has errno 2 (No such file or directory) > > > > ** > > > > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion > > > > failed (hdr.id == id): (7 == 73) > > > > Not sure this is related to this PR actually. Dave Gilbert reported on irc > > that he encountered a similar issue with 'make -j check', likely without > > these patches. > I was running on current master as of yesterday; no 9p specific patches. > > Dave They might be related as the "local/create_dir" test is already merged, but hard to say reliably without any data. How is reproducibility, sometimes / always? > > > > > ERROR qtest-x86_64: qos-test - Bail out! > > > > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion > > > > failed (hdr.id == id): (7 == 73) > > > > Makefile.mtest:3953: recipe for target 'run-test-492' failed > > > > > > > > > > > > thanks > > > > -- PMM > > > > > > So the 9p server is already failing to create the test case directory > > > "./qtest-9p-local/05/" relative to your current working directory. > > > > > > I would appreciate to get more info when you have some free cycles, as > > > I'm > > > unable to reproduce this on any system unfortunately. But no hurry as > > > these tests only become relevant actually for QEMU 6. > > > > > > What puzzles me is that the previous test cases succeeded there, which > > > all > > > > > > create their own test directory in the same way: > > > ./qtest-9p-local/01/ > > > ./qtest-9p-local/02/ (<-- dir vanishes after that test completed) > > > ./qtest-9p-local/03/ > > > ./qtest-9p-local/04/ > > > ... > > > > > > How does the "./qtest-9p-local/" directory look like after that > > > "local/symlink_file" test failed there? You can use this shortcut: > > > > > > export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 > > > cd build > > > tests/qtest/qos-test --verbose > > > ls -l qtest-9p-local > > > > > > That latter qos-test run will also output the assembled qemu command > > > line the 9p local tests would run with, which might also be helpful, > > > e.g. the relevant output would be something like this: > > > > > > GTest: run: > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vi > > > rtio-9p-tests/local/config (MSG: starting QEMU: exec > > > x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-7428.sock > > > -qtest-log /dev/null -chardev socket,path=/tmp/qtest-7428.qmp,id=char0 > > > -mon chardev=char0,mode=control -display none -M pc -fsdev > > > local,id=fsdev0,path='/home/me/git/qemu/build/qtest-9p-local',security_ > > > model=mapped-xattr -device > > > virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest) > > > > > > Would probably the test succeed if run alone? > > > > > > tests/qtest/qos-test -p > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vi > > > rtio-9p-tests/local/symlink_file > > > > > > Best regards, > > > Christian Schoenebeck Best regards, Christian Schoenebeck
* Christian Schoenebeck (qemu_oss@crudebyte.com) wrote: > On Dienstag, 27. Oktober 2020 10:06:53 CET Dr. David Alan Gilbert wrote: > > * Greg Kurz (groug@kaod.org) wrote: > > > On Mon, 26 Oct 2020 13:48:37 +0100 > > > > > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > > > > On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote: > > > > > On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck > > > > > > > > > > <qemu_oss@crudebyte.com> wrote: > > > > > > The following changes since commit > 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430: > > > > > > Merge remote-tracking branch > > > > > > 'remotes/kraxel/tags/modules-20201022-pull-request' into staging > > > > > > (2020-10-22 12:33:21 +0100)> > > > > > > > > > > > > are available in the Git repository at: > > > > > > https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023 > > > > > > > > > > > > for you to fetch changes up to > ee01926a11b1f9bffcd6cdec0961dd9d1882da71: > > > > > > tests/9pfs: add local Tunlinkat hard link test (2020-10-22 > > > > > > 20:26:33 > > > > > > +0200) > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > 9pfs: more tests using local fs driver > > > > > > > > > > > > Only 9pfs test case changes this time: > > > > > > > > > > > > * Refactor: Rename functions to make top-level test functions fs_*() > > > > > > > > > > > > easily distinguishable from utility test functions do_*(). > > > > > > > > > > > > * Refactor: Drop unnecessary function arguments in utility test > > > > > > > > > > > > functions. > > > > > > > > > > > > * More test cases using the 9pfs 'local' filesystem driver backend, > > > > > > > > > > > > namely for the following 9p requests: Tunlinkat, Tlcreate, > > > > > > Tsymlink > > > > > > and Tlink. > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > > > > I get a 'make check' failure on x86-64 Linux host: > > > > > > > > > > PASS 54 qtest-x86_64: qos-test > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v > > > > > irtio- 9p-tests/local/config PASS 55 qtest-x86_64: qos-test > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v > > > > > irtio- 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v > > > > > irtio- 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v > > > > > irtio- 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v > > > > > irtio- 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v > > > > > irtio- 9p-tests/local/symlink_file Received response 7 (RLERROR) > > > > > instead of 73 (RMKDIR) > > > > > Rlerror has errno 2 (No such file or directory) > > > > > ** > > > > > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion > > > > > failed (hdr.id == id): (7 == 73) > > > > > > Not sure this is related to this PR actually. Dave Gilbert reported on irc > > > that he encountered a similar issue with 'make -j check', likely without > > > these patches. > > I was running on current master as of yesterday; no 9p specific patches. > > > > Dave > > They might be related as the "local/create_dir" test is already merged, but > hard to say reliably without any data. > > How is reproducibility, sometimes / always? I think I was seeing a few different errors; but I was running make check -j 32 ish Dave > > > > > > > ERROR qtest-x86_64: qos-test - Bail out! > > > > > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion > > > > > failed (hdr.id == id): (7 == 73) > > > > > Makefile.mtest:3953: recipe for target 'run-test-492' failed > > > > > > > > > > > > > > > thanks > > > > > -- PMM > > > > > > > > So the 9p server is already failing to create the test case directory > > > > "./qtest-9p-local/05/" relative to your current working directory. > > > > > > > > I would appreciate to get more info when you have some free cycles, as > > > > I'm > > > > unable to reproduce this on any system unfortunately. But no hurry as > > > > these tests only become relevant actually for QEMU 6. > > > > > > > > What puzzles me is that the previous test cases succeeded there, which > > > > all > > > > > > > > create their own test directory in the same way: > > > > ./qtest-9p-local/01/ > > > > ./qtest-9p-local/02/ (<-- dir vanishes after that test completed) > > > > ./qtest-9p-local/03/ > > > > ./qtest-9p-local/04/ > > > > ... > > > > > > > > How does the "./qtest-9p-local/" directory look like after that > > > > "local/symlink_file" test failed there? You can use this shortcut: > > > > > > > > export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 > > > > cd build > > > > tests/qtest/qos-test --verbose > > > > ls -l qtest-9p-local > > > > > > > > That latter qos-test run will also output the assembled qemu command > > > > line the 9p local tests would run with, which might also be helpful, > > > > e.g. the relevant output would be something like this: > > > > > > > > GTest: run: > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vi > > > > rtio-9p-tests/local/config (MSG: starting QEMU: exec > > > > x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-7428.sock > > > > -qtest-log /dev/null -chardev socket,path=/tmp/qtest-7428.qmp,id=char0 > > > > -mon chardev=char0,mode=control -display none -M pc -fsdev > > > > local,id=fsdev0,path='/home/me/git/qemu/build/qtest-9p-local',security_ > > > > model=mapped-xattr -device > > > > virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest) > > > > > > > > Would probably the test succeed if run alone? > > > > > > > > tests/qtest/qos-test -p > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vi > > > > rtio-9p-tests/local/symlink_file > > > > > > > > Best regards, > > > > Christian Schoenebeck > > > Best regards, > Christian Schoenebeck > >
On Dienstag, 27. Oktober 2020 11:26:53 CET Dr. David Alan Gilbert wrote: > * Christian Schoenebeck (qemu_oss@crudebyte.com) wrote: > > On Dienstag, 27. Oktober 2020 10:06:53 CET Dr. David Alan Gilbert wrote: > > > * Greg Kurz (groug@kaod.org) wrote: > > > > On Mon, 26 Oct 2020 13:48:37 +0100 > > > > > > > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > > > > > On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote: > > > > > > On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck > > > > > > > > > > > > <qemu_oss@crudebyte.com> wrote: > > > > > > > The following changes since commit > > > > 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430: > > > > > > > Merge remote-tracking branch > > > > > > > 'remotes/kraxel/tags/modules-20201022-pull-request' into > > > > > > > staging > > > > > > > (2020-10-22 12:33:21 +0100)> > > > > > > > > > > > > > > are available in the Git repository at: > > > > > > > https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023 > > > > > > > > > > > > > > for you to fetch changes up to > > > > ee01926a11b1f9bffcd6cdec0961dd9d1882da71: > > > > > > > tests/9pfs: add local Tunlinkat hard link test (2020-10-22 > > > > > > > 20:26:33 > > > > > > > +0200) > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > 9pfs: more tests using local fs driver > > > > > > > > > > > > > > Only 9pfs test case changes this time: > > > > > > > > > > > > > > * Refactor: Rename functions to make top-level test functions > > > > > > > fs_*() > > > > > > > > > > > > > > easily distinguishable from utility test functions do_*(). > > > > > > > > > > > > > > * Refactor: Drop unnecessary function arguments in utility test > > > > > > > > > > > > > > functions. > > > > > > > > > > > > > > * More test cases using the 9pfs 'local' filesystem driver > > > > > > > backend, > > > > > > > > > > > > > > namely for the following 9p requests: Tunlinkat, Tlcreate, > > > > > > > Tsymlink > > > > > > > and Tlink. > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > > > > > > I get a 'make check' failure on x86-64 Linux host: > > > > > > > > > > > > PASS 54 qtest-x86_64: qos-test > > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio- > > > > > > 9p/v > > > > > > irtio- 9p-tests/local/config PASS 55 qtest-x86_64: qos-test > > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio- > > > > > > 9p/v > > > > > > irtio- 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test > > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio- > > > > > > 9p/v > > > > > > irtio- 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test > > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio- > > > > > > 9p/v > > > > > > irtio- 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test > > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio- > > > > > > 9p/v > > > > > > irtio- 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test > > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio- > > > > > > 9p/v > > > > > > irtio- 9p-tests/local/symlink_file Received response 7 (RLERROR) > > > > > > instead of 73 (RMKDIR) > > > > > > Rlerror has errno 2 (No such file or directory) > > > > > > ** > > > > > > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: > > > > > > assertion > > > > > > failed (hdr.id == id): (7 == 73) > > > > > > > > Not sure this is related to this PR actually. Dave Gilbert reported on > > > > irc > > > > that he encountered a similar issue with 'make -j check', likely > > > > without > > > > these patches. > > > > > > I was running on current master as of yesterday; no 9p specific patches. > > > > > > Dave > > > > They might be related as the "local/create_dir" test is already merged, > > but > > hard to say reliably without any data. > > > > How is reproducibility, sometimes / always? > > I think I was seeing a few different errors; but I was running make > check -j 32 ish > > Dave > Ok, I understand, but how frequently are you able to trigger one of the test failures there? Does it happen like every time, or rather just once every xth run or so? I'm running the qtests multi-threaded in a loop for several hours now, but so far I was unable to hit any test failure: #/bin/sh i=0 while true; do i=$[$i+1] echo '**************************************************' echo "* RUN $i *" echo '**************************************************' make check-qtest -j32 V=1 if [[ "$?" -ne 0 ]]; then echo "Aborted after $i runs due to failure" break fi done If you say it only happens once in a while, then I let it go for a day or more. However if it happens there quite frequently, then I guess I have to look into another aspect instead, like e.g. differences in the glib version. > > > > > > ERROR qtest-x86_64: qos-test - Bail out! > > > > > > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: > > > > > > assertion > > > > > > failed (hdr.id == id): (7 == 73) > > > > > > Makefile.mtest:3953: recipe for target 'run-test-492' failed > > > > > > > > > > > > > > > > > > thanks > > > > > > -- PMM > > > > > > > > > > So the 9p server is already failing to create the test case > > > > > directory > > > > > "./qtest-9p-local/05/" relative to your current working directory. > > > > > > > > > > I would appreciate to get more info when you have some free cycles, > > > > > as > > > > > I'm > > > > > unable to reproduce this on any system unfortunately. But no hurry > > > > > as > > > > > these tests only become relevant actually for QEMU 6. > > > > > > > > > > What puzzles me is that the previous test cases succeeded there, > > > > > which > > > > > all > > > > > > > > > > create their own test directory in the same way: > > > > > ./qtest-9p-local/01/ > > > > > ./qtest-9p-local/02/ (<-- dir vanishes after that test completed) > > > > > ./qtest-9p-local/03/ > > > > > ./qtest-9p-local/04/ > > > > > ... > > > > > > > > > > How does the "./qtest-9p-local/" directory look like after that > > > > > "local/symlink_file" test failed there? You can use this shortcut: > > > > > > > > > > export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 > > > > > cd build > > > > > tests/qtest/qos-test --verbose > > > > > ls -l qtest-9p-local > > > > > > > > > > That latter qos-test run will also output the assembled qemu command > > > > > line the 9p local tests would run with, which might also be helpful, > > > > > e.g. the relevant output would be something like this: > > > > > > > > > > GTest: run: > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p > > > > > /vi > > > > > rtio-9p-tests/local/config (MSG: starting QEMU: exec > > > > > x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-7428.sock > > > > > -qtest-log /dev/null -chardev > > > > > socket,path=/tmp/qtest-7428.qmp,id=char0 > > > > > -mon chardev=char0,mode=control -display none -M pc -fsdev > > > > > local,id=fsdev0,path='/home/me/git/qemu/build/qtest-9p-local',securi > > > > > ty_ > > > > > model=mapped-xattr -device > > > > > virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest) > > > > > > > > > > Would probably the test succeed if run alone? > > > > > > > > > > tests/qtest/qos-test -p > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p > > > > > /vi > > > > > rtio-9p-tests/local/symlink_file > > > > > > > > > > Best regards, > > > > > Christian Schoenebeck > > > > Best regards, > > Christian Schoenebeck
On Mon, 26 Oct 2020 at 12:48, Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > > On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote: > > I get a 'make check' failure on x86-64 Linux host: > > > > PASS 54 qtest-x86_64: qos-test > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > 9p-tests/local/config PASS 55 qtest-x86_64: qos-test > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio- > > 9p-tests/local/symlink_file Received response 7 (RLERROR) instead of 73 > > (RMKDIR) > > Rlerror has errno 2 (No such file or directory) > > ** > > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion > > failed (hdr.id == id): (7 == 73) > > ERROR qtest-x86_64: qos-test - Bail out! > > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion > > failed (hdr.id == id): (7 == 73) > > Makefile.mtest:3953: recipe for target 'run-test-492' failed I just got this again on an entirely different pullreq so that suggests that this is indeed an intermittent currently in master: PASS 49 qtest-i386/qos-test /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/synth/flush/ignored PASS 50 qtest-i386/qos-test /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/synth/readdir/basic PASS 51 qtest-i386/qos-test /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/synth/readdir/split_512 PASS 52 qtest-i386/qos-test /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/synth/readdir/split_256 PASS 53 qtest-i386/qos-test /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/synth/readdir/split_128 PASS 54 qtest-i386/qos-test /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config Received response 7 (RLERROR) instead of 73 (RMKDIR) Rlerror has errno 2 (No such file or directory) ** ERROR:../../tests/qtest/virtio-9p-test.c:296:v9fs_req_recv: assertion failed (hdr.id == id): (7 == 73) ERROR qtest-i386/qos-test - Bail out! ERROR:../../tests/qtest/virtio-9p-test.c:296:v9fs_req_recv: assertion failed (hdr.id == id): (7 == 73) Makefile.mtest:1857: recipe for target 'run-test-230' failed > So the 9p server is already failing to create the test case directory > "./qtest-9p-local/05/" relative to your current working directory. This sounds suspicious, because there's nothing in that filename that's specific to the test case being qtest-i386 and not qtest-something-else. How does the test harness deal with the possibility of the same virtio-9p-pci test being run in parallel for multiple guest architectures under a make -jN setup ? > What puzzles me is that the previous test cases succeeded there, which all > create their own test directory in the same way: > > ./qtest-9p-local/01/ > ./qtest-9p-local/02/ (<-- dir vanishes after that test completed) > ./qtest-9p-local/03/ > ./qtest-9p-local/04/ > ... After the build failed, the qtest-9p-local directory was empty. thanks -- PMM
On Donnerstag, 29. Oktober 2020 14:20:11 CET Peter Maydell wrote: > On Mon, 26 Oct 2020 at 12:48, Christian Schoenebeck > > <qemu_oss@crudebyte.com> wrote: > > On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote: > > > I get a 'make check' failure on x86-64 Linux host: > > > > > > PASS 54 qtest-x86_64: qos-test > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vir > > > tio- 9p-tests/local/config PASS 55 qtest-x86_64: qos-test > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vir > > > tio- 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vir > > > tio- 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vir > > > tio- 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vir > > > tio- 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vir > > > tio- 9p-tests/local/symlink_file Received response 7 (RLERROR) instead > > > of 73 (RMKDIR) > > > Rlerror has errno 2 (No such file or directory) > > > ** > > > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion > > > failed (hdr.id == id): (7 == 73) > > > ERROR qtest-x86_64: qos-test - Bail out! > > > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion > > > failed (hdr.id == id): (7 == 73) > > > Makefile.mtest:3953: recipe for target 'run-test-492' failed > > I just got this again on an entirely different pullreq so that > suggests that this is indeed an intermittent currently in master: > > PASS 49 qtest-i386/qos-test > /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p > -tests/synth/flush/ignored PASS 50 qtest-i386/qos-test > /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p > -tests/synth/readdir/basic PASS 51 qtest-i386/qos-test > /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p > -tests/synth/readdir/split_512 PASS 52 qtest-i386/qos-test > /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p > -tests/synth/readdir/split_256 PASS 53 qtest-i386/qos-test > /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p > -tests/synth/readdir/split_128 PASS 54 qtest-i386/qos-test > /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p > -tests/local/config Received response 7 (RLERROR) instead of 73 (RMKDIR) > Rlerror has errno 2 (No such file or directory) > ** > ERROR:../../tests/qtest/virtio-9p-test.c:296:v9fs_req_recv: assertion > failed (hdr.id == id): (7 == 73) > ERROR qtest-i386/qos-test - Bail out! > ERROR:../../tests/qtest/virtio-9p-test.c:296:v9fs_req_recv: assertion > failed (hdr.id == id): (7 == 73) > Makefile.mtest:1857: recipe for target 'run-test-230' failed > > > So the 9p server is already failing to create the test case directory > > "./qtest-9p-local/05/" relative to your current working directory. > > This sounds suspicious, because there's nothing in that filename > that's specific to the test case being qtest-i386 and not > qtest-something-else. How does the test harness deal with the > possibility of the same virtio-9p-pci test being run in parallel > for multiple guest architectures under a make -jN setup ? Aaaaah, now there we go! I was actually running the tests for 2 days and >3000 test suite runs now without a single 9p test failure, but ... not for multiple architectures simultaniously. Another point for centralizing test dir locations in future. > > > What puzzles me is that the previous test cases succeeded there, which all > > > > create their own test directory in the same way: > > ./qtest-9p-local/01/ > > ./qtest-9p-local/02/ (<-- dir vanishes after that test completed) > > ./qtest-9p-local/03/ > > ./qtest-9p-local/04/ > > ... > > After the build failed, the qtest-9p-local directory was empty. Yes, that suggests a parallel test suite was wiping the test directory './qtest-9p-local'. So I'll append the architecture to the test dir location. To nail it this time, anyting else that would come to your mind regarding test dirs? > > thanks > -- PMM Best regards, Christian Schoenebeck
On Thu, 29 Oct 2020 at 13:48, Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > So I'll append the architecture to the test dir location. To nail it this > time, anyting else that would come to your mind regarding test dirs? I think most tests that need a temp directory set one up using mkdtemp(). thanks -- PMM
On Donnerstag, 29. Oktober 2020 14:57:45 CET Peter Maydell wrote: > On Thu, 29 Oct 2020 at 13:48, Christian Schoenebeck > > <qemu_oss@crudebyte.com> wrote: > > So I'll append the architecture to the test dir location. To nail it this > > time, anyting else that would come to your mind regarding test dirs? > > I think most tests that need a temp directory set one > up using mkdtemp(). > > thanks > -- PMM Ok, I'll use mkdtemp() instead, that avoids other potential parallel config colissions that I may not have considered yet. The original motivation against mkdtemp() was that /tmp is isually a ramfs, hence very limited regarding large file tests. But that's not an issue right now. Thanks Peter! Best regards, Christian Schoenebeck
On Thu, 29 Oct 2020 13:57:45 +0000 Peter Maydell <peter.maydell@linaro.org> wrote: > On Thu, 29 Oct 2020 at 13:48, Christian Schoenebeck > <qemu_oss@crudebyte.com> wrote: > > So I'll append the architecture to the test dir location. To nail it this > > time, anyting else that would come to your mind regarding test dirs? > > I think most tests that need a temp directory set one > up using mkdtemp(). > Yeah, early versions of the 9p tests that were using the local fsdev backend relied on mkdtemp(). > thanks > -- PMM
On Thu, 29 Oct 2020 at 14:06, Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > Ok, I'll use mkdtemp() instead, that avoids other potential parallel config > colissions that I may not have considered yet. > > The original motivation against mkdtemp() was that /tmp is isually a ramfs, > hence very limited regarding large file tests. But that's not an issue right > now. How large is "large" here ? thanks -- PMM
On Donnerstag, 29. Oktober 2020 15:15:19 CET Peter Maydell wrote: > On Thu, 29 Oct 2020 at 14:06, Christian Schoenebeck > > <qemu_oss@crudebyte.com> wrote: > > Ok, I'll use mkdtemp() instead, that avoids other potential parallel > > config > > colissions that I may not have considered yet. > > > > The original motivation against mkdtemp() was that /tmp is isually a > > ramfs, > > hence very limited regarding large file tests. But that's not an issue > > right now. > > How large is "large" here ? > > thanks > -- PMM E.g. ~10 GiB which might be a problem for cloud based CI platforms. But again, we don't have any 9p test doing that yet. So mkdtemp() is just fine for now. Best regards, Christian Schoenebeck
On Thu, 29 Oct 2020 at 14:31, Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > > On Donnerstag, 29. Oktober 2020 15:15:19 CET Peter Maydell wrote: > > On Thu, 29 Oct 2020 at 14:06, Christian Schoenebeck > > > > <qemu_oss@crudebyte.com> wrote: > > > Ok, I'll use mkdtemp() instead, that avoids other potential parallel > > > config > > > colissions that I may not have considered yet. > > > > > > The original motivation against mkdtemp() was that /tmp is isually a > > > ramfs, > > > hence very limited regarding large file tests. But that's not an issue > > > right now. > > > > How large is "large" here ? > E.g. ~10 GiB which might be a problem for cloud based CI platforms. Yeah, 10GB is too big by an order of magnitude for anything in the standard "make check" set. It could go in an optional "I'm the 9p maintainer and I want to run a wider set of tests" target though. thanks -- PMM
On Thu, Oct 29, 2020 at 02:52:16PM +0000, Peter Maydell wrote: > On Thu, 29 Oct 2020 at 14:31, Christian Schoenebeck > <qemu_oss@crudebyte.com> wrote: > > > > On Donnerstag, 29. Oktober 2020 15:15:19 CET Peter Maydell wrote: > > > On Thu, 29 Oct 2020 at 14:06, Christian Schoenebeck > > > > > > <qemu_oss@crudebyte.com> wrote: > > > > Ok, I'll use mkdtemp() instead, that avoids other potential parallel > > > > config > > > > colissions that I may not have considered yet. > > > > > > > > The original motivation against mkdtemp() was that /tmp is isually a > > > > ramfs, > > > > hence very limited regarding large file tests. But that's not an issue > > > > right now. > > > > > > How large is "large" here ? > > > E.g. ~10 GiB which might be a problem for cloud based CI platforms. > > Yeah, 10GB is too big by an order of magnitude for anything in the > standard "make check" set. It could go in an optional "I'm the 9p > maintainer and I want to run a wider set of tests" target though. I think as a rough rule of thumb, tests should not create files that are larger than the size of the QEMU build dir, and if it is creating non-trivially sized files, then they should be created in the build dir, not /tmp. This probably puts 1 GB as a upper bound on size but bear in mind tests can run in parallel, so ideally biggest file sizes should be more in the 100s of MB range Regards, Daniel
On Donnerstag, 29. Oktober 2020 16:04:03 CET Daniel P. Berrangé wrote: > On Thu, Oct 29, 2020 at 02:52:16PM +0000, Peter Maydell wrote: > > On Thu, 29 Oct 2020 at 14:31, Christian Schoenebeck > > > > <qemu_oss@crudebyte.com> wrote: > > > On Donnerstag, 29. Oktober 2020 15:15:19 CET Peter Maydell wrote: > > > > On Thu, 29 Oct 2020 at 14:06, Christian Schoenebeck > > > > > > > > <qemu_oss@crudebyte.com> wrote: > > > > > Ok, I'll use mkdtemp() instead, that avoids other potential parallel > > > > > config > > > > > colissions that I may not have considered yet. > > > > > > > > > > The original motivation against mkdtemp() was that /tmp is isually a > > > > > ramfs, > > > > > hence very limited regarding large file tests. But that's not an > > > > > issue > > > > > right now. > > > > > > > > How large is "large" here ? > > > > > > E.g. ~10 GiB which might be a problem for cloud based CI platforms. > > > > Yeah, 10GB is too big by an order of magnitude for anything in the > > standard "make check" set. It could go in an optional "I'm the 9p > > maintainer and I want to run a wider set of tests" target though. > > I think as a rough rule of thumb, tests should not create files > that are larger than the size of the QEMU build dir, and if it is > creating non-trivially sized files, then they should be created in > the build dir, not /tmp. This probably puts 1 GB as a upper bound > on size but bear in mind tests can run in parallel, so ideally biggest > file sizes should be more in the 100s of MB range > > Regards, > Daniel I definitely won't run such large-file tests uncaged, so it would not run by default for sure. But sooner or later it would make sense to streamline test case options in QEMU in general, so that certain tests would automatically run or not depending on runner's capabilities, limits and preferences. The TCG tests for instance periodically trigger test failures as they exceed Travis-CI's runtime limit of 40mins once in a while. Back to the actual 9p test failure issue, I think I will go for something like this: diff --git a/tests/qtest/libqos/virtio-9p.c b/tests/qtest/libqos/virtio-9p.c index d43647b3b7..ebbacd5896 100644 --- a/tests/qtest/libqos/virtio-9p.c +++ b/tests/qtest/libqos/virtio-9p.c @@ -35,7 +35,12 @@ static char *concat_path(const char* a, const char* b) static void init_local_test_path(void) { char *pwd = g_get_current_dir(); - local_test_path = concat_path(pwd, "qtest-9p-local"); + char *template = concat_path(pwd, "qtest-9p-local-XXXXXX"); + local_test_path = mkdtemp(template); + if (!local_test_path) { + g_test_message("mkdtemp('%s') failed: %s", template, strerror(errno)); + } + g_assert(local_test_path); g_free(pwd); } @@ -246,11 +251,6 @@ static void virtio_9p_register_nodes(void) const char *str_simple = "fsdev=fsdev0,mount_tag=" MOUNT_TAG; const char *str_addr = "fsdev=fsdev0,addr=04.0,mount_tag=" MOUNT_TAG; - /* make sure test dir for the 'local' tests exists and is clean */ - init_local_test_path(); - remove_local_test_dir(); - create_local_test_dir(); - QPCIAddress addr = { .devfn = QPCI_DEVFN(4, 0), }; @@ -278,3 +278,14 @@ static void virtio_9p_register_nodes(void) } libqos_init(virtio_9p_register_nodes); + +static void __attribute__((constructor)) construct_virtio_9p(void) { + /* make sure test dir for the 'local' tests exists */ + init_local_test_path(); + create_local_test_dir(); +} + +static void __attribute__((destructor)) destruct_virtio_9p(void) { + /* remove previously created test dir when test suite completed */ + remove_local_test_dir(); +} So it would still use the current directory instead of /tmp/ and would create and remove the test dir on process start/end. I wanted to avoid using constructor/destructor atttributes, as some compilers don't support them, but it seems it's already used in the code base and there are currently no setup/teardown callbacks in libqos. Another downside: with 'make check -jN' this will temporarily create a bunch of unused, empty dirs. But I hope that's Ok to fix in QEMU 6 (by adding setup/teardown callbacks to libqos later). Just hoping there are no glib versions that use threads instead of processes. Best regards, Christian Schoenebeck
On Thu, Oct 29, 2020 at 06:27:21PM +0100, Christian Schoenebeck wrote: > On Donnerstag, 29. Oktober 2020 16:04:03 CET Daniel P. Berrangé wrote: > > On Thu, Oct 29, 2020 at 02:52:16PM +0000, Peter Maydell wrote: > > > On Thu, 29 Oct 2020 at 14:31, Christian Schoenebeck > > > > > > <qemu_oss@crudebyte.com> wrote: > > > > On Donnerstag, 29. Oktober 2020 15:15:19 CET Peter Maydell wrote: > > > > > On Thu, 29 Oct 2020 at 14:06, Christian Schoenebeck > > > > > > > > > > <qemu_oss@crudebyte.com> wrote: > > > > > > Ok, I'll use mkdtemp() instead, that avoids other potential parallel > > > > > > config > > > > > > colissions that I may not have considered yet. > > > > > > > > > > > > The original motivation against mkdtemp() was that /tmp is isually a > > > > > > ramfs, > > > > > > hence very limited regarding large file tests. But that's not an > > > > > > issue > > > > > > right now. snip > @@ -278,3 +278,14 @@ static void virtio_9p_register_nodes(void) > } > > libqos_init(virtio_9p_register_nodes); > + > +static void __attribute__((constructor)) construct_virtio_9p(void) { > + /* make sure test dir for the 'local' tests exists */ > + init_local_test_path(); > + create_local_test_dir(); > +} > + > +static void __attribute__((destructor)) destruct_virtio_9p(void) { > + /* remove previously created test dir when test suite completed */ > + remove_local_test_dir(); > +} > > So it would still use the current directory instead of /tmp/ and would > create and remove the test dir on process start/end. I wanted to avoid > using constructor/destructor atttributes, as some compilers don't > support them, but it seems it's already used in the code base and there > are currently no setup/teardown callbacks in libqos. QEMU explicitly only supports CLang and GCC, and our code assumes constructors/destructors work. IOW, you should ignore the portability concern. We don't care about other vendor compilers with poor feature sets. Regards, Daniel
The following changes since commit 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430: Merge remote-tracking branch 'remotes/kraxel/tags/modules-20201022-pull-request' into staging (2020-10-22 12:33:21 +0100) are available in the Git repository at: https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023 for you to fetch changes up to ee01926a11b1f9bffcd6cdec0961dd9d1882da71: tests/9pfs: add local Tunlinkat hard link test (2020-10-22 20:26:33 +0200) ---------------------------------------------------------------- 9pfs: more tests using local fs driver Only 9pfs test case changes this time: * Refactor: Rename functions to make top-level test functions fs_*() easily distinguishable from utility test functions do_*(). * Refactor: Drop unnecessary function arguments in utility test functions. * More test cases using the 9pfs 'local' filesystem driver backend, namely for the following 9p requests: Tunlinkat, Tlcreate, Tsymlink and Tlink. ---------------------------------------------------------------- Christian Schoenebeck (8): tests/9pfs: simplify do_mkdir() tests/9pfs: add local Tunlinkat directory test tests/9pfs: add local Tlcreate test tests/9pfs: add local Tunlinkat file test tests/9pfs: add local Tsymlink test tests/9pfs: add local Tunlinkat symlink test tests/9pfs: add local Tlink test tests/9pfs: add local Tunlinkat hard link test Greg Kurz (5): tests/9pfs: Factor out do_version() helper tests/9pfs: Set alloc in fs_create_dir() tests/9pfs: Factor out do_attach() helper tests/9pfs: Turn fs_readdir_split() into a helper tests/9pfs: Turn fs_mkdir() into a helper tests/qtest/virtio-9p-test.c | 467 +++++++++++++++++++++++++++++++++++++++---- 1 file changed, 431 insertions(+), 36 deletions(-)