Date:	Tue, 25 Aug 2015 00:40:15 +0100
From:	Ken Moffat <zarniwhoop@...world.com>
To:	linux-kernel@...r.kernel.org
Cc:	qemu-devel@...gnu.org
Subject: Lockups with 4.2-rc kernels and qemu

(Cc'ing qemu-devel, please keep me in the Cc).

TL;DR - qemu locks up my machine when I use 4.2-rc kernels.

I only use qemu from time to time, mostly to test changes to my own
scripts, or new package versions, in beyond.linuxfromscratch.org.  A
few days ago I came back to that, building an LFS system from the
beginning of this month and then using that to try out my changes.
In the beginning I built a 4.2-rc5 kernel and booted that system in
qemu-2.4.0.

I had several lockups along the way from a minimal system to the end
of my attempts to build a full desktop, and in fact I dropped back
to a 4.1 kernel and qemu-2.3.0 before I completed the build.  Mostly,
the qemu system appeared to have been idle when the box locked up, or
else idle apart from xscreensaver, but on one occasion it ran through
several steps to build Xorg protocol header packages - I write a
'stamp' file so that I can resume after a failure, and several of
these were created, but empty (instead of a small amount of version,
time, space data) and it later turned out that nothing had been
installed for those packages.

In all cases I have nothing relevant in either the guest or the host
logs.  On one or two occasions I got the flashing keyboard LEDs.

After the initial problems I ran memtest86+ for 10 hours without any
errors.

In the end, I dropped back to a 4.1 kernel and also qemu-2.3.0
because my concern was to finish the build.  I was thinking -
erroneously, of course - that this was a qemu problem.  Gradually, I
moved to 4.2-rc kernels and things appeared to be ok.  But today I
installed 4.2-rc8 and thought about trying to create a test-case to
see if the kernel+qemu combination is probably ok.  I decided to
start qemu, login, run startx [ xscreensaver will be invoked,
otherwise userspace is idle ], and leave it for 3 hours - lockups
varied in how long they took to appear, but all were in 2 hours or
less.  So, I left -rc8 and qemu-2.3.0, and when I returned to it
after about 3 and a quarter hours the box had locked up.

The machine is an AMD phenom (not always the most reliable, I had to
drop caches today to get it to reliably build -rc8 with make -j 4
but otherwise it seems to have not needed that in the past month).
I'll attach the kernel config.

I compiled qemu-2.3.0 with:

sed -i '/resource/ i#include <sys/xattr.h>' \
  fsdev/virtfs-proxy-helper.c

./configure --prefix=/usr \
        --sysconfdir=/etc \
        --docdir=/usr/share/doc/qemu-2.3.0 \
        --target-list=x86_64-softmmu \
        --audio-drv-list=alsa

and I use a wrapper script for qemu which tells me that what I am
actually running is:

qemu-system-x86_64 -enable-kvm -hda svn20150803-32-desk2.img -hdb
svn-logging-tools.img  -m 2G -usb -usbdevice tablet -show-cursor
-display sdl  -cpu kvm32 -monitor stdio -smp 4 -vga std

That was for building a new system, later runs only use a -hda
image.  And all of the uses have been for i686 guests.

The host (and the initial guest used to build the new system) is
gcc-5.1.0, the newly built guests 5.2.0; binutils 2.25 / 2.25.1;
glibc 2.21 throughout.

Because I need to leave the system running for up to 3 hours to get
an idea if a particular kernel is ok, I don't think this problem
lends itself to bisection.

Any suggestions, please ?

ĸen
-- 
This one goes up to eleven: but only on a clear day, with the wind in
the right direction.

View attachment "config-4.2-rc8.phenom" of type "text/plain" (82611 bytes)

Powered by blists - more mailing lists