Hello,

    I have tried qemu_kvm 0.12.4 release and also git from about 1/2
an hour ago.  In both cases, I crash in the post_kvm_run() function on
the line about:

pthread_mutex_lock(&qemu_mutex);

The command I use to run qemu worked great with
glibc-2.11.1,linux-2.6.32.14,and gcc-4.4.3,
but I have upgraded to glibc-2.11.2, linux-2.6.34, and gcc-4.4.4 and get this:

(gdb) bt
#0  post_kvm_run (kvm=0x84cde04, env=0x84e7168)
    at /tmp/qemu-kvm-201006282359/qemu-kvm.c:566
#1  0x08086ccf in kvm_run (env=0x84e7168)
    at /tmp/qemu-kvm-201006282359/qemu-kvm.c:619
#2  0x080882d0 in kvm_cpu_exec (env=0x84e7168)
    at /tmp/qemu-kvm-201006282359/qemu-kvm.c:1238
#3  0x08088cf6 in kvm_main_loop_cpu (env=0x84e7168)
    at /tmp/qemu-kvm-201006282359/qemu-kvm.c:1495
#4  0x08088e72 in ap_main_loop (_env=0x84e7168)
    at /tmp/qemu-kvm-201006282359/qemu-kvm.c:1541
#5  0x55598690 in start_thread () from /lib/libpthread.so.0
#6  0x55a8ca7e in clone () from /lib/libc.so.6
(gdb) list
561     in /tmp/qemu-kvm-201006282359/qemu-kvm.c
(gdb) print qemu_mutex
$1 = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0,
    __nusers = 0, {__spins = 0, __list = {__next = 0x0}}},
  __size = '\000' <repeats 23 times>, __align = 0}
(gdb)

I rebuilt the kernel, then glibc, then the entire graphics stack, then
qemu_kvm to try and be sure I have no problems about headers.  All my
other software works, but qemu_kvm does not.  About 1 time in 10 it
will actually run fine, but the other times it will crash as shown.  I
use a dedicated LV for this.  I have a 32bit userland with a 64bit
kernel.  Here is the script I use:

#! /sbin/bash
INSTANCE=0
NAME=VM${INSTANCE}
FAKEDISK=/dev/mapper/vmland-vmdisk${INSTANCE}
((MACNO=22+INSTANCE))
ulimit -S -c unlimited
echo qemu-system-x86_64 \
  -cpu core2duo -smp 2 -m 512 \
  -vga std \
  -vnc :${INSTANCE} -monitor stdio \
  -localtime -usb -usbdevice mouse \
  -net nic,vlan=0,model=rtl8139,macaddr=DE:AD:BE:EF:25:${MACNO} \
  -net 
tap,ifname=tap${INSTANCE},script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
\
  -name ${NAME} \
  -hda ${FAKEDISK} \
  -boot c
qemu-system-x86_64 \
  -cpu core2duo -smp 2 -m 512 \
  -vga std \
  -vnc :${INSTANCE} -monitor stdio \
  -localtime -usb -usbdevice mouse \
  -net nic,vlan=0,model=rtl8139,macaddr=DE:AD:BE:EF:25:${MACNO} \
  -net 
tap,ifname=tap${INSTANCE},script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
\
  -name ${NAME} \
  -hda ${FAKEDISK} \
  -boot c
# just in case
/usr/sbin/brctl delif br0 tap${INSTANCE}

The bridging and taps all worked before.   The CPU is a core i7 950,
I've got 12GB of RAM, and I'm going nuts trying to debug this.  Since
it sometimes works, I wonder if there is some uninitialized variable
that sometimes is set so I get lucky but usually is set where things
crash.

I don't want to place blame, I just want to get it working.  Any
hints?  I'm not subscribed, but the page at
http://www.linux-kvm.org/page/Lists,_IRC said it's ok to send a
message anyway.  Please cc: me so I get a copy, or if I need to join
the list please tell me.

I compile it all from source (similar to linux from scratch) so there
is no upstream distro to go ask for help.  Since everything else
works, I suspect something strange in qemu_kvm.  I did google a lot
but found nothing helpful.

The ISO image used works on real hardware, and uses the same kernel
and userland.  The isolinux shows the menu and works great, but when
it is time to boot the kernel I get the crash.

The kernel modules kvm and kvm_intel are loaded when I try to start qemu_kvm.

The /var/log/messages just shows this:

Jun 29 00:05:47 banpuk kernel: [20299.236926] qemu-system-x86[31375]:
segfault at 14 ip 0000000008086a64 sp 000000005601e180 error 4 in
qemu-system-x86_64[8048000+256000]

The /var/log/syslog show this:

Jun 29 00:06:00 banpuk kernel: [20312.302498] kvm: 31383: cpu0
unhandled wrmsr: 0x198 data 0
Jun 29 00:06:00 banpuk kernel: [20312.302606] kvm: 31383: cpu1
unhandled wrmsr: 0x198 data 0

JGH
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to