qemu-block
[Top][All Lists]
Advanced

[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



reply via email to

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