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/[email protected]/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
