On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn <hahn@xxxxxxxxxxxxx> wrote: > Hello, > > I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 on an Debian > based system using AMD64 CPUs. During the install, the system froze (progress > bar didn't advance) and kvm was slowly eating CPU cycles on the host. > > $ dpkg-query -W libvirt0 qemu-kvm linux-image-`uname -r` > libvirt0 0.8.7-1.48.201102031226 > linux-image-2.6.32-ucs37-amd64 2.6.32-30.37.201102031101 > qemu-kvm 0.12.4+dfsg-1~bpo50+1.3.201010011432 > > It was started using virsh, which generated the following command line: > /usr/bin/kvm.bin -S \ > -M pc-0.12 \ > -enable-kvm \ > -m 768 \ > -smp 1,sockets=1,cores=1,threads=1 \ > -name 7-Professional_amd64 \ > -uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \ > -nodefaults \ > -chardev > socket,id=monitor,path=/var/lib/libvirt/qemu/7-Professional_amd64.monitor,server,nowait > \ > -mon chardev=monitor,mode=readline \ > -rtc base=utc \ > -boot dc \ > -drive > file=/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 > -device > virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \ > -drive > file=/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw > -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ > -drive > file=/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw > -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ > -device > virtio-net-pci,vlan=0,id=net0,mac=52:54:00:f7:da:b5,bus=pci.0,addr=0x3 > \ > -net tap,fd=20,vlan=0,name=hostnet0 \ > -usb \ > -device usb-tablet,id=input0 \ > -vnc 0.0.0.0:0 \ > -k de \ > -vga cirrus \ > -incoming exec:cat \ > -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \ > -no-kvm-irqchip > > The "-no-kvm-irqchip"-Option was added, because we experienced shutdown/resume > problems with other machines, which either received no interrupts anymore or > where caught in their interrupt service routine, never being able to > acknowledge the interrupts. Adding that option solved that problem, but might > be causing other problems now. > > Using gdb I was able to track down Windows hanging in the following routine, > which look like some spin-lock / semaphore aquire() implementation: > (gdb) x/20i 0xfffff8000c485a80 > 0xfffff8000c485a80: mov %rbx,0x8(%rsp) > 0xfffff8000c485a85: push %rdi > 0xfffff8000c485a86: sub $0x20,%rsp > 0xfffff8000c485a8a: mov %rcx,%rdi > 0xfffff8000c485a8d: xor %ebx,%ebx > 0xfffff8000c485a8f: nop > 0xfffff8000c485a90: inc %ebx > 0xfffff8000c485a92: test %ebx,0x274834(%rip) # 0xfffff8000c6fa2cc > 0xfffff8000c485a98: je 0xfffff8000c48adad > 0xfffff8000c485a9e: pause > 0xfffff8000c485aa0: mov (%rdi),%rcx > 0xfffff8000c485aa3: test %rcx,%rcx > 0xfffff8000c485aa6: jne 0xfffff8000c485a90 > 0xfffff8000c485aa8: lock btsq $0x0,(%rdi) > 0xfffff8000c485aae: jb 0xfffff8000c485a90 > 0xfffff8000c485ab0: mov %ebx,%eax > 0xfffff8000c485ab2: mov 0x30(%rsp),%rbx > 0xfffff8000c485ab7: add $0x20,%rsp > 0xfffff8000c485abb: pop %rdi > 0xfffff8000c485abc: retq > (gdb) x/w 0xfffff8000c6fa2cc > 0xfffff8000c6fa2cc: 0xffffffff > (gdb) x/w $rdi > 0xfffffa800131f600: 0x00000001 > > Did someone experience similar problems or does somebody know if there was a > fix for such a problem in newer kvm- or Linux-kernel versions? > > We also encountered problems with some Windows Versions when using VirtIO with > Qcow2 images, which were using backing-files for copy-on-write: they just > crashed with a blue-screen. Just changing from the CoW-qcow2 to the > master-qcow2 file "fixed" the problem, but this isn't satisfactory, since we > would like to use the CoW-functionality. Not using VirtIO also fixed the > problem, but has performance penalties. Vadim: Any suggestions for extracting more relevant information in these cases? One option may might be to set up the Windows debugger in order to closely monitor what the guest is doing when it hangs or BSODs: http://etherboot.org/wiki/sanboot/winnt_iscsi_debug Stefan -- 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
