* RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
@ 2011-02-17 10:44 Philipp Hahn
2011-02-17 11:30 ` Stefan Hajnoczi
0 siblings, 1 reply; 8+ messages in thread
From: Philipp Hahn @ 2011-02-17 10:44 UTC (permalink / raw)
To: kvm
[-- Attachment #1: Type: text/plain, Size: 4436 bytes --]
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.
Any help or comment is appreciated.
BYtE
Philipp
--
Philipp Hahn Open Source Software Engineer hahn@univention.de
Univention GmbH Linux for Your Business fon: +49 421 22 232- 0
Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99
http://www.univention.de/
** Besuchen Sie uns auf der CeBIT in Hannover **
** Auf dem Univention Stand D36 in Halle 2 **
** Vom 01. bis 05. März 2011 **
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
2011-02-17 10:44 RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2 Philipp Hahn
@ 2011-02-17 11:30 ` Stefan Hajnoczi
2011-02-17 11:41 ` Gleb Natapov
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Hajnoczi @ 2011-02-17 11:30 UTC (permalink / raw)
To: Philipp Hahn; +Cc: kvm, Vadim Rozenfeld
On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn <hahn@univention.de> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
2011-02-17 11:30 ` Stefan Hajnoczi
@ 2011-02-17 11:41 ` Gleb Natapov
2011-02-17 12:45 ` Vadim Rozenfeld
0 siblings, 1 reply; 8+ messages in thread
From: Gleb Natapov @ 2011-02-17 11:41 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: Philipp Hahn, kvm, Vadim Rozenfeld
On Thu, Feb 17, 2011 at 11:30:25AM +0000, Stefan Hajnoczi wrote:
> On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn <hahn@univention.de> 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
>
Why is is linked to virtio? Does install on ide work? Does install work
without -no-kvm-irqchip (which had pretty serious problem till now)?
Adding -no-kvm-irqchip usually does not solve problems, but just
exchange one set of bugs to the other (and reduces performance
drastically).
--
Gleb.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
2011-02-17 11:41 ` Gleb Natapov
@ 2011-02-17 12:45 ` Vadim Rozenfeld
2011-02-17 14:26 ` Stefan Hajnoczi
2011-02-17 15:27 ` Philipp Hahn
0 siblings, 2 replies; 8+ messages in thread
From: Vadim Rozenfeld @ 2011-02-17 12:45 UTC (permalink / raw)
To: Philipp Hahn; +Cc: Stefan Hajnoczi, Gleb Natapov, kvm
On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote:
> On Thu, Feb 17, 2011 at 11:30:25AM +0000, Stefan Hajnoczi wrote:
> > On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn <hahn@univention.de> 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?
Debugging installation-phase problems on 64-bit platforms is a very
complicated thing. If the problem is reproducible on x86 platforms, you
can try printing messages (RhelDbgPrint function) to localize the
problem. You will need to adjust RhelDbgLevel in virtio_stor.c and build
checked (debug) version of the driver.
> >
> > 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
> >
> Why is is linked to virtio? Does install on ide work? Does install work
> without -no-kvm-irqchip (which had pretty serious problem till now)?
> Adding -no-kvm-irqchip usually does not solve problems, but just
> exchange one set of bugs to the other (and reduces performance
> drastically).
>
Does it work on Win7-32? :)
> --
> Gleb.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
2011-02-17 12:45 ` Vadim Rozenfeld
@ 2011-02-17 14:26 ` Stefan Hajnoczi
2011-02-17 14:53 ` Vadim Rozenfeld
2011-02-17 15:27 ` Philipp Hahn
1 sibling, 1 reply; 8+ messages in thread
From: Stefan Hajnoczi @ 2011-02-17 14:26 UTC (permalink / raw)
To: Vadim Rozenfeld; +Cc: Philipp Hahn, Gleb Natapov, kvm
On Thu, Feb 17, 2011 at 12:45 PM, Vadim Rozenfeld <vrozenfe@redhat.com> wrote:
> On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote:
>> On Thu, Feb 17, 2011 at 11:30:25AM +0000, Stefan Hajnoczi wrote:
>> > On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn <hahn@univention.de> 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?
> Debugging installation-phase problems on 64-bit platforms is a very
> complicated thing. If the problem is reproducible on x86 platforms, you
> can try printing messages (RhelDbgPrint function) to localize the
> problem. You will need to adjust RhelDbgLevel in virtio_stor.c and build
> checked (debug) version of the driver.
Is that even possible - I thought these drivers need to be signed on
recent versions of Windows?
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
2011-02-17 14:26 ` Stefan Hajnoczi
@ 2011-02-17 14:53 ` Vadim Rozenfeld
0 siblings, 0 replies; 8+ messages in thread
From: Vadim Rozenfeld @ 2011-02-17 14:53 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: Philipp Hahn, Gleb Natapov, kvm
On Thu, 2011-02-17 at 14:26 +0000, Stefan Hajnoczi wrote:
> On Thu, Feb 17, 2011 at 12:45 PM, Vadim Rozenfeld <vrozenfe@redhat.com> wrote:
> > On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote:
> >> On Thu, Feb 17, 2011 at 11:30:25AM +0000, Stefan Hajnoczi wrote:
> >> > On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn <hahn@univention.de> 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?
> > Debugging installation-phase problems on 64-bit platforms is a very
> > complicated thing. If the problem is reproducible on x86 platforms, you
> > can try printing messages (RhelDbgPrint function) to localize the
> > problem. You will need to adjust RhelDbgLevel in virtio_stor.c and build
> > checked (debug) version of the driver.
>
> Is that even possible - I thought these drivers need to be signed on
> recent versions of Windows?
only 64-bit versions of Windows Vista and later require kernel mode code
signing (KMCS) in order to load kernel-mode software.
>
> Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
2011-02-17 12:45 ` Vadim Rozenfeld
2011-02-17 14:26 ` Stefan Hajnoczi
@ 2011-02-17 15:27 ` Philipp Hahn
2011-02-17 16:02 ` Vadim Rozenfeld
1 sibling, 1 reply; 8+ messages in thread
From: Philipp Hahn @ 2011-02-17 15:27 UTC (permalink / raw)
To: Vadim Rozenfeld; +Cc: Stefan Hajnoczi, Gleb Natapov, kvm
[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]
Hello,
Am Donnerstag 17 Februar 2011 13:45:34 schrieb Vadim Rozenfeld:
> On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote:
> > Why is is linked to virtio? Does install on ide work?
Yes, works without the VirtIO block driver using IDE.
> > Does install work
> > without -no-kvm-irqchip (which had pretty serious problem till now)?
> > Adding -no-kvm-irqchip usually does not solve problems, but just
> > exchange one set of bugs to the other (and reduces performance
> > drastically).
I'll try again without -no-kvm-irqchip, newer KVM and newer Kernel, but last
time I tested kvm-0.13 and Linux-2.6.37 with the same results, see
<http://article.gmane.org/gmane.comp.emulators.kvm.devel/66069>
> Does it work on Win7-32? :)
I also had problems with Windows XP 32Bit: Installation taking more than 20
minutes with no noticeable progress, also VirtIO (probably an older version,
I don't have that instance any more)
BYtE
Philipp
--
Philipp Hahn Open Source Software Engineer hahn@univention.de
Univention GmbH Linux for Your Business fon: +49 421 22 232- 0
Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99
http://www.univention.de/
** Besuchen Sie uns auf der CeBIT in Hannover **
** Auf dem Univention Stand D36 in Halle 2 **
** Vom 01. bis 05. März 2011 **
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
2011-02-17 15:27 ` Philipp Hahn
@ 2011-02-17 16:02 ` Vadim Rozenfeld
0 siblings, 0 replies; 8+ messages in thread
From: Vadim Rozenfeld @ 2011-02-17 16:02 UTC (permalink / raw)
To: Philipp Hahn; +Cc: Stefan Hajnoczi, Gleb Natapov, kvm
On Thu, 2011-02-17 at 16:27 +0100, Philipp Hahn wrote:
> Hello,
>
> Am Donnerstag 17 Februar 2011 13:45:34 schrieb Vadim Rozenfeld:
> > On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote:
> > > Why is is linked to virtio? Does install on ide work?
>
> Yes, works without the VirtIO block driver using IDE.
>
> > > Does install work
> > > without -no-kvm-irqchip (which had pretty serious problem till now)?
> > > Adding -no-kvm-irqchip usually does not solve problems, but just
> > > exchange one set of bugs to the other (and reduces performance
> > > drastically).
>
> I'll try again without -no-kvm-irqchip, newer KVM and newer Kernel, but last
> time I tested kvm-0.13 and Linux-2.6.37 with the same results, see
> <http://article.gmane.org/gmane.comp.emulators.kvm.devel/66069>
>
> > Does it work on Win7-32? :)
>
> I also had problems with Windows XP 32Bit: Installation taking more than 20
> minutes with no noticeable progress, also VirtIO (probably an older version,
> I don't have that instance any more)
Could you please try "cache=writethrough" on virtio drive?
Best regards,
Vadim
>
> BYtE
> Philipp
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-02-17 16:02 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-17 10:44 RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2 Philipp Hahn
2011-02-17 11:30 ` Stefan Hajnoczi
2011-02-17 11:41 ` Gleb Natapov
2011-02-17 12:45 ` Vadim Rozenfeld
2011-02-17 14:26 ` Stefan Hajnoczi
2011-02-17 14:53 ` Vadim Rozenfeld
2011-02-17 15:27 ` Philipp Hahn
2011-02-17 16:02 ` Vadim Rozenfeld
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox