Re: [Qemu-block] [Qemu-devel] [PATCH v1 0/8] testing/next

[Alex Bennée]

Thomas Huth <address@hidden> writes:

> On 20/02/2019 21.52, Alex Bennée wrote:
>>
>> Alex Bennée <address@hidden> writes:
>>
>>> Hi,
>>>
>>>   tests/boot-sector.c:161:boot_sector_test:
>>>     assertion failed (signature == SIGNATURE): (0x0000face == 0x0000dead)
>>>
>>> I have seen this locally and got a core dump but it doesn't show much.
>>> I'm going to see if I can get more out of a debug build. It is
>>> generated by:
>>>
>>>   tests/cdrom-test -m=quick -k --tap
>>>
>>> I think the subtest is:
>>>
>>>   /x86_64/cdrom/boot/isapc
>>>
>>> Attaching to the child QEMU looks like it is eternally returning
>>> -EINTR and looping around with the occasionally kvm_handle_io to port
>>> 146 and port 112. I guess under test conditions this eventually times
>>> out and dies.
>> <snip>
>>
>> This is load related. I can run:
>>
>>   retry.py --timeout 600 -n 500 -c -- \
>>     env QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 \
>>         QTEST_QEMU_IMG=qemu-img ./tests/cdrom-test \
>>         -m=quick -p /x86_64/cdrom/boot/isapc
>>
>> and then all 500 run fine. If I do the same while running a make check
>> check-tcg -j9 in another build directory it hangs within 20 odd
>> attempts.
>>
>> Can anyone else reproduce this?

I should also mention my current config for the reproducer test is:

  '../../configure' '--python=python3' '--disable-docs' '--disable-tools' 
'--disable-libusb' '--disable-vte' '--disable-xen' '--enable-debug' 
'--extra-cflags=-O0 -g3' '--target-list=x86_64-softmmu'

>
> I can't reproduce it here. Might be worth a try to check the BIOS output
> in that case. Add this patch:
>
> diff --git a/tests/cdrom-test.c b/tests/cdrom-test.c
> index 14bd981..c38e016 100644
> --- a/tests/cdrom-test.c
> +++ b/tests/cdrom-test.c
> @@ -132,7 +132,7 @@ static void add_x86_tests(void)
>      qtest_add_data_func("cdrom/boot/virtio-scsi",
>                          "-device virtio-scsi -device scsi-cd,drive=cdr "
>                          "-blockdev file,node-name=cdr,filename=", 
> test_cdboot);
> -    qtest_add_data_func("cdrom/boot/isapc", "-M isapc "
> +    qtest_add_data_func("cdrom/boot/isapc", "-M isapc -vga none -device sga 
> -serial file:/tmp/stdio "
>                          "-drive if=ide,media=cdrom,file=", test_cdboot);
>      qtest_add_data_func("cdrom/boot/am53c974",
>                          "-device am53c974 -device scsi-cd,drive=cd1 "
>
> ... then check /tmp/stdio when it hangs.

This gets us:

  SeaBIOS (version rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org)
  Booting from Floppy...
  Boot failed: could not read the boot disk

  Booting from DVD/CD...
  Boot failed: Could not read from CDROM (code 000c)
  Booting from DVD/CD...
  Boot failed: Could not read from CDROM (code 0003)
  Booting from Hard Disk...
  Boot failed: could not read the boot disk

  No bootable device.

I tried to bisect but this occurs even in v3.0.0

  SeaBIOS (version rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org)
  Booting from Floppy...
  Boot failed: could not read the boot disk

  Booting from DVD/CD...
  Boot failed: Could not read from CDROM (code 000c)
  Booting from DVD/CD...
  Boot failed: Could not read from CDROM (code 0003)
  Booting from Hard Disk...
  Boot failed: could not read the boot disk

  No bootable device.

Can I pass this over to the block/bios people to look at. I think at
this point I think the test has always been unstable but tends only to
trigger the fault on Travis because it is highly loaded.

In the meantime I'll see if I can disable the test for the CI runs.

--
Alex Bennée