[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH v1 0/8] testing/next
From: |
Thomas Huth |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH v1 0/8] testing/next |
Date: |
Thu, 21 Feb 2019 17:21:23 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 |
On 21/02/2019 14.00, Alex Bennée wrote:
>
> 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
Weird, if it also occurs with 3.0 already, why didn't we notice this
earlier?
> In the meantime I'll see if I can disable the test for the CI runs.
Ok, but that likely means nobody is going to fix it anymore ... anyway,
if we still keep it for the SPEED=slow mode, we will at least still
notice if it breaks completely one day...
Thomas