Bug 756895 - RAM overcommit course qemu-kvm core dumps during win7_64 installation
Summary: RAM overcommit course qemu-kvm core dumps during win7_64 installation
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Orit Wasserman
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-25 02:32 UTC by Xiaoqing Wei
Modified: 2014-03-04 00:24 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-27 10:36:58 UTC
Target Upstream Version:


Attachments (Terms of Use)
gdb bt full (14.79 KB, text/plain)
2011-11-25 02:36 UTC, Xiaoqing Wei
no flags Details
yet another core dump (25.98 KB, text/plain)
2011-11-25 03:15 UTC, Xiaoqing Wei
no flags Details

Description Xiaoqing Wei 2011-11-25 02:32:23 UTC
Description of problem:

qemu-kvm core dumps during win7_64 installation
Version-Release number of selected component (if applicable):

qemu-kvm-0.12.1.2-2.210.el6.x86_64
How reproducible:

5 / 50
Steps to Reproduce:
1. start a win7_64 installation by:
/home/staf-kvm-devel/autotest-devel/client/tests/kvm/qemu -name 'vm1' -chardev socket,id=qmp_monitor_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20111122-165744-STUN,server,nowait -mon chardev=qmp_monitor_id_qmpmonitor1,mode=control \
-chardev socket,id=serial_id_20111122-165744-STUN,path=/tmp/serial-N,server,nowait \
-device isa-serial,chardev=serial_id_20111122-165744-STUN \
-drive file='win7-64.qcow2',index=0,if=none,id=drive-ide0-0-0,media=disk,cache=none,format=qcow2,aio=native \
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \
-device rtl8139,netdev=idvdg4cO,mac=9a:fe:9d:9b:b9:96,id=ndev00idvdg4cO,bus=pci.0,addr=0x3 \
-netdev tap,id=idvdg4cO,fd=21 \
-m 4G -smp 4,cores=2,threads=1,sockets=2 \
-drive file='en_windows_7_ultimate_with_sp1_x64_dvd_618240.iso',index=1,if=none,id=drive-ide0-0-1,media=cdrom,readonly=on,format=raw \
-device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
-drive file='winutils.iso',index=2,if=none,id=drive-ide0-1-0,media=cdrom,readonly=on,format=raw \
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \
-drive file='virtio-win.iso',index=3,if=none,id=drive-ide0-1-1,media=cdrom,readonly=on,format=raw \
-device ide-drive,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 \
-cpu cpu64-rhel6,+sse2,+x2apic \
-fda '/home/staf-kvm-devel/autotest-devel/client/tests/kvm/images/win7-64/answer.vfd' \
-spice port=8000,disable-ticketing -vga qxl \
-rtc base=localtime,clock=host,driftfix=slew \
-boot order=cdn,once=d,menu=off     -M rhel6.2.0 -usb -device usb-tablet -enable-kvm 
2.
3.
  
Actual results:

qemu-kvm core dumps during installation.
Expected results:

installation finish, both guest and host works well.

Additional info:
   NOTE: bt_full is attached.
Program terminated with signal 6, Aborted.
#0  0x00000030c4032885 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0x00000030c4032885 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00000030c4034065 in abort () at abort.c:92
#2  0x00000000004847b0 in qemu_memalign (alignment=2097152, size=8589934592) at osdep.c:112
#3  0x00000000004ece62 in qemu_ram_alloc_from_ptr (dev=<value optimized out>, 
    name=<value optimized out>, size=8589934592, host=<value optimized out>)
    at /usr/src/debug/qemu-kvm-0.12.1.2/exec.c:2730
#4  0x0000000000452903 in pc_init1 (ram_size=3758096384, boot_device=0x7fff452c7270 "d", 
    kernel_filename=0x0, kernel_cmdline=0x643102 "", initrd_filename=0x0, 
    cpu_model=0x7fff452c85a0 "cpu64-rhel6,+sse2,+x2apic", pci_enabled=1)
    at /usr/src/debug/qemu-kvm-0.12.1.2/hw/pc.c:1115
#5  0x000000000040d4de in main (argc=<value optimized out>, argv=<value optimized out>, 
    envp=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/vl.c:6259
(gdb)

Comment 1 Xiaoqing Wei 2011-11-25 02:36:00 UTC
Created attachment 536129 [details]
gdb bt full

Comment 3 Xiaoqing Wei 2011-11-25 03:15:04 UTC
Created attachment 536137 [details]
yet another core dump

Comment 4 Xiaoqing Wei 2011-11-25 03:16:14 UTC
AND here's another core dump , looks different:

#0  0x0000000000496d6a in alloc_refcount_block (bs=0x2e1e010, offset=4584051076082565690, length=<value optimized out>, addend=-1) at block/qcow2-refcount.c:334
(gdb) #0  0x0000000000496d6a in alloc_refcount_block (bs=0x2e1e010, offset=4584051076082565690, length=<value optimized out>, addend=-1) at block/qcow2-refcount.c:334
#1  update_refcount (bs=0x2e1e010, offset=4584051076082565690, length=<value optimized out>, addend=-1) at block/qcow2-refcount.c:459
#2  0x00000000004975e0 in qcow2_free_clusters (bs=0x2e1e010, offset=4584051076082565690, size=65536) at block/qcow2-refcount.c:639
#3  0x0000000000498cee in qcow2_alloc_cluster_link_l2 (bs=0x2e1e010, m=<value optimized out>) at block/qcow2-cluster.c:672
#4  0x0000000000493ea8 in qcow2_aio_write_cb (opaque=0x2ffff10, ret=0) at block/qcow2.c:642
#5  0x0000000000485d6a in qemu_laio_process_completion (s=<value optimized out>, laiocb=0x7f63e0000950) at linux-aio.c:68
#6  0x0000000000485f7f in qemu_laio_enqueue_completed (opaque=0x2e1be80) at linux-aio.c:107
#7  qemu_laio_completion_cb (opaque=0x2e1be80) at linux-aio.c:144
#8  0x000000000040c46f in main_loop_wait (timeout=1000) at /usr/src/debug/qemu-kvm-0.12.1.2/vl.c:4024
#9  0x000000000042af2a in kvm_main_loop () at /usr/src/debug/qemu-kvm-0.12.1.2/qemu-kvm.c:2225
#10 0x000000000040deb5 in main_loop (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/vl.c:4234
#11 main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/vl.c:6470

Comment 5 Xiaoqing Wei 2011-11-25 05:41:54 UTC
(In reply to comment #4)
> AND here's another core dump , looks different:
> 

Sorry, according to the gdb outputs, 

commnent #4  [ and attachment "yet another core dump (25.98 KB, text/plain) "]

should be a different bug, already filed a new bug:

Bug 756915 - qemu-kvm core dumps and disk corrupt during win7_64 installation

Thanks and Best Regards,
Xiaoqing Wei.

Comment 7 Dor Laor 2011-11-27 10:36:58 UTC
Why do you think this is a bug? How much have you over committed the host?
It is perfectly normal to fail memory allocation. We should report it in a nicer way thought.

Comment 8 Xiaoqing Wei 2011-11-29 04:42:06 UTC
(In reply to comment #7)
Hi Dor,

I gave the guest all the physical RAM on the host  (eg: the host has 8GB RAM installed, then add "-m 8192 " to cmd.)

and the host has 8GB of swap.


Thanks,
Xiaoqing Wei.

Comment 9 juzhang 2011-11-29 05:02:06 UTC
Would you please tell us can we do some restrictions before boot guest instead of hit core dump in the progress of using?form the user point,

For example
Host RAM is 4G,I booted guest with 20G
#/usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 20G -smp 2,sockets=1,cores=2,threads=1 -name rhel6.2sp164  -drive file=/root/win08-new.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,serial=zhang,cache=none,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2
Results:
Guest can not be booted at the beginning with the friendly messages
Failed to allocate 21474836480 B: Cannot allocate memory
Aborted (core dumped)

form user point,we think this is more friendly,would you please tell us can we make it?


Note You need to log in before you can comment on or make changes to this bug.