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@tumbleweed:/tmp> cat /proc/version
Linux version 4.13.12-1-vanilla (geeko@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
(mockbu...@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
// Robert
// Robert
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
