Re: Windows 2003, virtio Ethernet and USB - Strange Interaction
Sven Rudolph [EMAIL PROTECTED] writes: Dor Laor [EMAIL PROTECTED] writes: Sven Rudolph wrote: ... Trying a summary: When using virtio Ethernet and -usb; Windows leaves something (virtio Ethernet or USB ?) in a state that isn't reset by my reboot sequence (etherboot/pxegrub) and makes the next Windows boot hang. Booting Linux inbetween resets that state, and using the -boot c path does that too. ... It seems like the virtio and the usb root hub share the same pci irq. Probably on reboot the usb root hub does not reset the irq status and just after boot the driver gets into infnit loop. This problem still appeared with kvm-79, but it went away in kvm-80. Whoever solved this: Thank you! Sven -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows 2003, virtio Ethernet and USB - Strange Interaction
Dor Laor [EMAIL PROTECTED] writes: Sven Rudolph wrote: ... Trying a summary: When using virtio Ethernet and -usb; Windows leaves something (virtio Ethernet or USB ?) in a state that isn't reset by my reboot sequence (etherboot/pxegrub) and makes the next Windows boot hang. Booting Linux inbetween resets that state, and using the -boot c path does that too. ... It seems like the virtio and the usb root hub share the same pci irq. Probably on reboot the usb root hub does not reset the irq status and just after boot the driver gets into infnit loop. Can you try to compile the following: diff --git a/qemu/hw/usb-uhci.c b/qemu/hw/usb-uhci.c index b90cf78..773ad54 100644 --- a/qemu/hw/usb-uhci.c +++ b/qemu/hw/usb-uhci.c @@ -1098,6 +1098,7 @@ void usb_uhci_piix3_init(PCIBus *bus, int devfn) s-frame_timer = qemu_new_timer(vm_clock, uhci_frame_timer, s); uhci_reset(s); + qemu_register_reset(uhci_reset, s); /* Use region 4 for consistency with real hardware. BSD guests seem to rely on this. */ @@ -1135,6 +1136,7 @@ void usb_uhci_piix4_init(PCIBus *bus, int devfn) s-frame_timer = qemu_new_timer(vm_clock, uhci_frame_timer, s); uhci_reset(s); + qemu_register_reset(uhci_reset, s); /* Use region 4 for consistency with real hardware. BSD guests seem to rely on this. */ This patch didn't help... Alternatively you can try -no-kvm-irqchip ... but this option helps. I hope this is a useful hint for finding the origin of the problem. Thanks, Sven -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Windows 2003, virtio Ethernet and USB - Strange Interaction
Hello, I have an (as far as I understand it) complex problem. I just got some good debugging hints, so I tried some more things and reproduced the problem with recent KVM. I tested it now with kvm-76 (both kernel and userspace) with virtio Ethernet on Linux 2.6.27-rc7. The guest runs Windows Server 2003 (Standard Edition, SP2) with the virtio guest driver (Version 5.1.0.3107). First a description of my environment. I start KVM's qemu: /usr/local/bin/qemu-system-x86_64 -m 3584 -boot n -hda hda.dat \ -net nic,macaddr=00:50:56:24:0b:37,model=virtio \ -net tap,ifname=vm03,script=no,downscript=no \ -usb -usbdevice tablet This does a DHCP request via an etherboot virtio rom; it reports the version as Etherboot 5.4.3, the MD5 sum is: 9b3dbc97cc819508f2984ac00b90adc0 /usr/local/share/qemu/pxe-virtio.bin This starts pxegrub; pxegrub configuration is compiled-in and boots from harddisk: default 0 timeout 5 title boot from first disk root (hd0) chainloader +1 (This is our way of configuring DHCP to boot the locally-installed Windows. In order to boot a network Linux, the DHCP configuration is automatically changed.) Now the problem: When I reboot Windows (shutdown /r), the newly booted windows hangs during boot. (The problem stays the same when I reset the VM (using the monitor command system_reset) instead of rebooting with shutdown /r.) It hangs in the first graphical screen (where the windows logo and Microsoft Windows Server 2003 are displayed in the center), and the activity bar below this stops after some seconds (and qemu starts eating 100% CPU). Resetting the VM with system_reset does not solve the problem; the next booted Windows hangs in the same place. There are many ways that make the problem disappear: When I stop the qemu process and start a new one, Windows boots again (but the problem can be reproduced by rebooting Windows as described above). When I reset the VM with system_reset, boot Linux (Version 2.6.25.9) from network, reboot this Linux and then boot Windows again, it works. When I use the Realtek network driver (model=rtl8139), Windows boots again. When I do not use the network boot, etherboot and pxegrub sequence (using -boot c instead of -boot n), Windows boots again. And now the real fun: when I remove the -usb -usbdevice tablet option (and this is the only change!), everything works. (It is the -usb part that makes the difference, -usbdevice tablet doesn't influence this problem.) I have no idea how virtio Ethernet and USB interact in order to cause this problem... Trying a summary: When using virtio Ethernet and -usb; Windows leaves something (virtio Ethernet or USB ?) in a state that isn't reset by my reboot sequence (etherboot/pxegrub) and makes the next Windows boot hang. Booting Linux inbetween resets that state, and using the -boot c path does that too. So my first workaround would be to not use the USB tablet, because this isn't critical for me. But it took us some time to diagnose the problem, hence I wanted to tell you about this in order to save you the same work. Sven -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows 2003, virtio Ethernet and USB - Strange Interaction
Le mardi 30 septembre 2008 à 10:41 +0200, Sven Rudolph a écrit : Hello, I have an (as far as I understand it) complex problem. I just got some good debugging hints, so I tried some more things and reproduced the problem with recent KVM. I tested it now with kvm-76 (both kernel and userspace) with virtio Ethernet on Linux 2.6.27-rc7. The guest runs Windows Server 2003 (Standard Edition, SP2) with the virtio guest driver (Version 5.1.0.3107). First a description of my environment. I start KVM's qemu: /usr/local/bin/qemu-system-x86_64 -m 3584 -boot n -hda hda.dat \ -net nic,macaddr=00:50:56:24:0b:37,model=virtio \ -net tap,ifname=vm03,script=no,downscript=no \ -usb -usbdevice tablet This does a DHCP request via an etherboot virtio rom; it reports the version as Etherboot 5.4.3, the MD5 sum is: 9b3dbc97cc819508f2984ac00b90adc0 /usr/local/share/qemu/pxe-virtio.bin Where is coming from your rom ? Is etherboot or gPXE rom ? This starts pxegrub; pxegrub configuration is compiled-in and boots from harddisk: default 0 timeout 5 title boot from first disk root (hd0) chainloader +1 (This is our way of configuring DHCP to boot the locally-installed Windows. In order to boot a network Linux, the DHCP configuration is automatically changed.) Is linux able to reboot ? Now the problem: When I reboot Windows (shutdown /r), the newly booted windows hangs during boot. (The problem stays the same when I reset the VM (using the monitor command system_reset) instead of rebooting with shutdown /r.) It hangs in the first graphical screen (where the windows logo and Microsoft Windows Server 2003 are displayed in the center), and the activity bar below this stops after some seconds (and qemu starts eating 100% CPU). Resetting the VM with system_reset does not solve the problem; the next booted Windows hangs in the same place. There are many ways that make the problem disappear: When I stop the qemu process and start a new one, Windows boots again (but the problem can be reproduced by rebooting Windows as described above). When I reset the VM with system_reset, boot Linux (Version 2.6.25.9) from network, reboot this Linux and then boot Windows again, it works. When I use the Realtek network driver (model=rtl8139), Windows boots again. When I do not use the network boot, etherboot and pxegrub sequence (using -boot c instead of -boot n), Windows boots again. And now the real fun: when I remove the -usb -usbdevice tablet option (and this is the only change!), everything works. (It is the -usb part that makes the difference, -usbdevice tablet doesn't influence this problem.) I have no idea how virtio Ethernet and USB interact in order to cause this problem... Did you try to reduce the amount of memory (-m 1024) ? Trying a summary: When using virtio Ethernet and -usb; Windows leaves something (virtio Ethernet or USB ?) in a state that isn't reset by my reboot sequence (etherboot/pxegrub) and makes the next Windows boot hang. Booting Linux inbetween resets that state, and using the -boot c path does that too. So my first workaround would be to not use the USB tablet, because this isn't critical for me. But it took us some time to diagnose the problem, hence I wanted to tell you about this in order to save you the same work. Regards, Laurent -- - [EMAIL PROTECTED] -- La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever. Saint Exupéry -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows 2003, virtio Ethernet and USB - Strange Interaction
Laurent Vivier [EMAIL PROTECTED] writes: Le mardi 30 septembre 2008 à 10:41 +0200, Sven Rudolph a écrit : Hello, I have an (as far as I understand it) complex problem. I just got some good debugging hints, so I tried some more things and reproduced the problem with recent KVM. I tested it now with kvm-76 (both kernel and userspace) with virtio Ethernet on Linux 2.6.27-rc7. The guest runs Windows Server 2003 (Standard Edition, SP2) with the virtio guest driver (Version 5.1.0.3107). First a description of my environment. I start KVM's qemu: /usr/local/bin/qemu-system-x86_64 -m 3584 -boot n -hda hda.dat \ -net nic,macaddr=00:50:56:24:0b:37,model=virtio \ -net tap,ifname=vm03,script=no,downscript=no \ -usb -usbdevice tablet This does a DHCP request via an etherboot virtio rom; it reports the version as Etherboot 5.4.3, the MD5 sum is: 9b3dbc97cc819508f2984ac00b90adc0 /usr/local/share/qemu/pxe-virtio.bin Where is coming from your rom ? http://www.mail-archive.com/kvm@vger.kernel.org/msg00631.html Is etherboot or gPXE rom ? It says Etherboot 5.4.3. I just tried a gPXE Image from http://rom-o-matic.net (Version 0.9.4 and git (gpxe-0.9.4-virtio-net.rom and gpxe-git-virtio-net.rom)), and it behaves the same. This starts pxegrub; pxegrub configuration is compiled-in and boots from harddisk: default 0 timeout 5 title boot from first disk root (hd0) chainloader +1 (This is our way of configuring DHCP to boot the locally-installed Windows. In order to boot a network Linux, the DHCP configuration is automatically changed.) Is linux able to reboot ? When Linux runs, the virtio Ethernet works fine. It can be rebooted, and when I do it, the freshly booted Linux and its virtio Ethernet still work fine. Now the problem: When I reboot Windows (shutdown /r), the newly booted windows hangs during boot. (The problem stays the same when I reset the VM (using the monitor command system_reset) instead of rebooting with shutdown /r.) It hangs in the first graphical screen (where the windows logo and Microsoft Windows Server 2003 are displayed in the center), and the activity bar below this stops after some seconds (and qemu starts eating 100% CPU). Resetting the VM with system_reset does not solve the problem; the next booted Windows hangs in the same place. There are many ways that make the problem disappear: When I stop the qemu process and start a new one, Windows boots again (but the problem can be reproduced by rebooting Windows as described above). When I reset the VM with system_reset, boot Linux (Version 2.6.25.9) from network, reboot this Linux and then boot Windows again, it works. When I use the Realtek network driver (model=rtl8139), Windows boots again. When I do not use the network boot, etherboot and pxegrub sequence (using -boot c instead of -boot n), Windows boots again. And now the real fun: when I remove the -usb -usbdevice tablet option (and this is the only change!), everything works. (It is the -usb part that makes the difference, -usbdevice tablet doesn't influence this problem.) I have no idea how virtio Ethernet and USB interact in order to cause this problem... Did you try to reduce the amount of memory (-m 1024) ? I just tested it, the problem still appears. Trying a summary: When using virtio Ethernet and -usb; Windows leaves something (virtio Ethernet or USB ?) in a state that isn't reset by my reboot sequence (etherboot/pxegrub) and makes the next Windows boot hang. Booting Linux inbetween resets that state, and using the -boot c path does that too. So my first workaround would be to not use the USB tablet, because this isn't critical for me. But it took us some time to diagnose the problem, hence I wanted to tell you about this in order to save you the same work. Thanks, Sven -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
