[OE-core] Good news Re: Yocto Project Status WW47’17

[Robert Yang]

Hi RP,

On 11/28/2017 06:47 PM, Robert Yang wrote:
> 
> 
> On 11/28/2017 03:49 PM, Robert Yang wrote:
>>
>> On 11/23/2017 06:20 PM, Richard Purdie wrote:
>>> On Mon, 2017-11-20 at 20:22 -0500, Randy MacLeod wrote:
>>>>> o   Issues with 4.13.10 host kernels booting kvm x86 guests on
>>>>> Tumbleweed (Suse) and Fedora 26 (attempting to see if 4.13.12
>>>>> helps)
>>>> Robert, can you test Fedora 26. It would help to have a defect open
>>>> with steps to reproduce or
>>>> something about the typical workflow/ build time/ day of the week/
>>>> phase of the moon.
>>>
>>> We have some further data:
>>>
>>> a) The issue occurs on 4.13.12
>>>
>>> rpurdie at tumbleweed:/tmp> cat /proc/version
>>> Linux version 4.13.12-1-vanilla (geeko at buildhost) (gcc version 7.2.1 20171020 
>>> [gcc-7-branch revision 253932] (SUSE Linux)) #1 SMP PREEMPT Wed Nov 8 
>>> 11:21:09 UTC 2017 (9151c66)
>>>
>>> b) The hang usually occurs at the TIMER line in the kernel logs but can
>>> occur after booting into userspace around the udevd line, or
>>> occasionally later in the boot process.
>>>
>>> c) The similarity between this and the ppc bug I worked on make me
>>> strongly suspect qemu's timers are stopping firing and the guest is
>>> sitting in the idle loop.
>>>
>>> d) I do now have a way to brute force the hangs at will. The attached
>>> "runqemu-parallel.py" script runs 50 qemus in parallel. In around 45s I
>>> had 10 hung on the autobuilder. I can provide more info on using that
>>> script if its not obvious. It does assume my recent master changes to
>>> the qemuconf files so we don't need to run bitbake -e to run runqemu.
>>>
>>> This could well be the same kind of locking issue we saw on ppc. I'll
>>> continue to look into that.
>>>
>>> Hopefully this extra information will put us on a good track to
>>> resolving it now. It is continuing to break builds and stop patch
>>> merging.
>>
>> I modified the script to run on my host (I used qemux86, not qemux86-64,
>> the later one is still in building) (Up to date Fedora 26, the kernel
>> is 4.13.13):
>>
>> $ cat /proc/version
>> Linux version 4.13.13-200.fc26.x86_64 
>> (mockbuild at bkernel01.phx2.fedoraproject.org) (gcc version 7.2.1 20170915 (Red 
>> Hat 7.2.1-2) (GCC)) #1 SMP Wed Nov 15 15:46:36 UTC 2017
>>
>> But didn't see any hangs after 10 minutes, all the qemus reached login. So maybe
>> it had been fixed on 4.13.13 ?
> 
> I tested qemux86-64, the boot became very slow (just like hang), no one booted
> after about 2 hours (still in booting). And it only happened when
> use qemux86-64 + kvm:
> 
> # Works
> $ runqemu tmp/deploy/images/qemux86-64/ nographic snapshot
> 
> # Doesn't work, like hang:
> $ runqemu tmp/deploy/images/qemux86-64/ nographic snapshot kvm

I upgraded qemu-native to qemu-2.11.0-rc2, then no hangs any more. I dropped
the conflicted patches during upgrade. I will send a formal upgrade tomorrow
it this is acceptable.

Here is the draft patch for testing:

   git://git.openembedded.org/openembedded-core-contrib rbt/qemu_test
   http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/qemu_test

Robert Yang (1):
   qemu: 2.10.1 -> 2.11.0-rc2 (test)

// Robert

> 
> // Robert
> 
>>
>> // Robert
>>
>>>
>>> Cheers,
>>>
>>> Richard
>>>