[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH v1 0/8] testing/next
From: |
Alex Bennée |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH v1 0/8] testing/next |
Date: |
Thu, 21 Feb 2019 13:00:29 +0000 |
User-agent: |
mu4e 1.1.0; emacs 26.1 |
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
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 0/8] testing/next,
Alex Bennée <=