Hello,
Software:
We use a 32bit userland with a 64bit kernel. In the qemu-kvm I
run the same distribution (using 64bit kernel with 32bit userland).
The userland is compiled with gcc-4.4.4, binutils-2.20.51.0.9,
glibc-2.11.2. The kernels are compiled using a crosstool-ng toolchain
generated for x86_64, using crosstool-ng-1.7.0. This crosstool
toolchain uses gcc-4.4.3, binutils-2.20, glibc-2.9. Except for the
KVM issue, kernels work fine for me built with this toolchain. Most
people seem to use 64bit userlands with 64bit kernels so perhaps
configurations like mine are not well tested yet.
Hardware:
The CPU is core i7 950 3GHz part, stepping 5. The machine has
12GB of RAM. Motherboard is a Gigabyte X58A-UD3R, Award BIOS version
F3 from 02/06/2010. 6 SATA hard disks, one SATA DVD burner. Machine
runs fine with 2.6.32.14 kernel. With 2.6.33.x or 2.6.34 it runs fine
except for KVM. Graphics card is a RV710 [Radeon HD 4350], but we
turn off KMS for radeon in the kenrel configuration since radeon with
KMS is unusuable (on all of of our machines, not just that one; intel
+ KMS works fine, but intel refuses to sell separate graphics cards).
We use the vesa driver in the xorg.conf instead. Normally (and during
all the testing and git bisect) we do not run the X windows on that
machine, but qemu-kvm wants the libraries. Client machine (Dell
Optiplex 330) runs the same setup, but with intel+KMS and gvncviewer
from gtk_vnc-0.3.10. Client machine can do qemu without KVM just
fine, but of course it is so slow it isn't really practical to use.
Compilation details:
The qemu-kvm version 0.12.4 is compiled with this:
./configure \
--prefix=/usr \
--enable-sdl \
--audio-drv-list=alsa \
--audio-card-list=ac97 \
--enable-mixemu \
--disable-xen \
--enable-curses \
--enable-bluez \
--enable-kvm \
--enable-nptl \
--enable-user-pie \
--target-list="x86_64-softmmu"
It requires this patch first to build on our systems:
diff -Naur qemu-0.12.3.old/configure qemu-0.12.3.new/configure
--- qemu-0.12.3.old/configure 2010-02-24 03:54:38.000000000 +0700
+++ qemu-0.12.3.new/configure 2010-03-25 14:43:43.000000000 +0700
@@ -1072,7 +1072,7 @@
int main(void) { return 0; }
EOF
if compile_prog "$sdl_cflags" "$sdl_libs" ; then
- sdl_libs="$sdl_libs -lX11"
+ sdl_libs="$sdl_libs -L/usr/X11R7/lib -lX11"
fi
if test "$mingw32" = "yes" ; then
sdl_libs="`echo $sdl_libs | sed s/-mwindows//g` -mconsole"
The SDL-1.2.14 is built like this:
./configure \
--prefix=/usr \
--mandir=/usr/man \
--infodir=/usr/info \
--sysconfdir=/etc \
--disable-rpath \
--disable-nls \
--disable-joystick \
--disable-oss \
--disable-esd \
--disable-arts \
--disable-mintaudio \
--disable-ipod \
--disable-input-tslib \
--disable-atari-ldg \
--x-includes=/usr/X11R7/include \
--x-libraries=/usr/X11R7/lib \
--with-x \
--build=i686-pc-linux-gnu
Access:
I can arrange for you to log in (and have root) on the actual machine.
I can make an ISO with the actual distribution for your download, or
mail you a DVD with express mail if that is better for you. The
machine is dedicated for doing KVM work, so I can run any tests you
want if you prefer I do them.
I worry about exceeding the list limits, but I can send kernel config
file, or any other information about the environment you want, or put
it somewhere for web download.
Other testing:
I did test on the only other machine I have control with hardware
support for virtualization, an older technology quad-core intel
machine, and hit identical problems (2.6.32.14 works with KVM,
anything 2.6.33 or newer does not, same toolchain and userland), so I
don't think it is a problem in the hardware.
Segfault description:
With qemu-kvm, the segfault happens after extlinux starts the kernel
and the kernel is uncompressing, but then the client window closes so
fast I cannot see exactly how far it gets. It does not get to a long
prompt, and the boot inside the KVM is into text mode. The same ISO
works with qemu without kvm on the client box with SDL or with
gvncviewer, but is too slow to be practical to use. My suspiscion is
that there is a 32/64 issue in the kernel kvm (or glibc threads) that
people doing 32/32 or 64/64 don't see, and 32/64 is uncommon. Since
it works sometimes (maybe 1 in 10 or 15 tries) it acts like a bad read
in a program where once in a while you get lucky and the random value
read lets the program run, like if you load al but mean ax, and
sometimes ah is 0 so using ax works, but usually it is not so ax has
trash in the top part and does not work (an 8/16 issue).
JGH
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
