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
