qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Co


From: Kevin Wolf
Subject: Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)
Date: Tue, 19 Feb 2019 12:38:40 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

Am 19.02.2019 um 11:11 hat Thomas Huth geschrieben:
> On 19/02/2019 10.37, Kevin Wolf wrote:
> > Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
> >> On 19/02/2019 08.53, Kevin Wolf wrote:
> [...]
> >>> Which are the cases that fail for you with '--disable-tcg'?
> >>
> >> These tests are failing: 087 169 188 232 235 238
> > 
> > Hm, 087 and 232 just do something like:
> > 
> >     $QEMU_PROG -nodefaults -machine accel=qtest -nographic \
> >                -qmp stdio -serial none \
> >                ...some -drive and -object options...
> > 
> > This should be fine with --disable-tcg, I think?
> > 
> > 169 runs a VM, but I don't see anything that makes it use TCG.
> > 
> > 188 doesn't even run QEMU at all, it's only qemu-io. I don't see how
> > this could be possibly related to --disable-tcg.
> 
> 087 and 188 obviously simply lack a check for the required crypto
> support.

Ah, okay, I thought you meant your whole list fails because of
--disable-tcg. Makes sense then.

> 169 got killed via abort():
> 
> 169                [08:34:39] [08:34:46] [failed, exit status 1] - output 
> mismatch (see 169.out.bad)
> --- /builds/huth/qemu/tests/qemu-iotests/169.out      2019-02-19 
> 08:23:54.000000000 +0000
> +++ /builds/huth/qemu/tests/qemu-iotests/169.out.bad  2019-02-19 
> 08:34:46.000000000 +0000
> @@ -1,5 +1,29 @@
> -....................
> +WARNING:qemu:qemu received signal 6: 
> /builds/huth/qemu/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64 
> -chardev 
> socket,id=mon,path=/tmp/qemu-iotests-quick-25045/tmpGQOExQ/qemua-13044-monitor.sock
>  -mon chardev=mon,mode=control -display none -vga none -qtest 
> unix:path=/tmp/qemu-iotests-quick-25045/qemua-13044-qtest.sock -machine 
> accel=qtest -nodefaults -machine accel=qtest -drive 
> if=virtio,id=drive0,file=/tmp/qemu-iotests-quick-25045/disk_a,format=qcow2,cache=writeback
> [...]
> 
> No clue why.

In order to debug failures like this, I usually enable core dumps.

> 232 is also strange, no idea what is going on here:
> 
> 232                [08:38:53] [08:38:56] - output mismatch (see 232.out.bad)
> --- /builds/huth/qemu/tests/qemu-iotests/232.out      2019-02-19 
> 08:23:54.000000000 +0000
> +++ /builds/huth/qemu/tests/qemu-iotests/232.out.bad  2019-02-19 
> 08:38:56.000000000 +0000
> @@ -21,13 +21,13 @@
>  NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>  NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>  
> -QEMU_PROG: -drive 
> driver=file,file=TEST_DIR/t.IMGFMT,if=none,read-only=off,auto-read-only=off: 
> Could not open 'TEST_DIR/t.IMGFMT': Permission denied
> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
> -
> -QEMU_PROG: -drive 
> driver=file,file=TEST_DIR/t.IMGFMT,if=none,auto-read-only=off: Could not open 
> 'TEST_DIR/t.IMGFMT': Permission denied
> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
> +
> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
> +NODE_NAME: TEST_DIR/t.IMGFMT (file)

Do you run the tests as root? This messes with any tests that try to
test read-only cases because root can write to everything, no matter
what the permissions say.

> >> By the way, 235 and 238 also fail on my normal laptop with RHEL7:
> >> [...]
> >> Any ideas what might be going on here?
> > 
> > I think it's most likely that QEMU just prints an error message on
> > startup and exits.
> Right, I finally found the issue:
> 
> qemu-system-x86_64: -machine accel=kvm: No accelerator found
> 
> I apparently compiled my QEMU with --disable-kvm at one point in time and
> forgot to enable it later again. ==> These tests should really check whether
> KVM is available in QEMU before they blindly use this feature.

Ideally, they shouldn't use it at all.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]