[Qemu-devel] Re: hi, may I ask some help on the paravirtualization of KVM?
Liang YANG wrote: Maybe I solove the problem. I use the qemu-img make a new GustOS img. And install the debian5 on the image file with option -net nic, model=virtio. ./x86_64-softmmu/qemu-system-x86_64 -hda debian.img -cdrom debian.iso -net nic, model=virtio This email reads as: -net nic, model=virtio If this is in fact what you're running with, the whitespace is broken; correct would be to have no space after the comma, as so: -net nic,model=virtio
[Qemu-devel] Re: Network connections stalling (due to lost interrupts/ticks?)
[Resending as the last copy seems to have been lost in the ether -- it certainly isn't in the GMANE archive] Well, behavior with the patch applied is certainly different. The large download I'm running still times out; however, it is now able to resume without needing to bring the interface down and back up. However, after the first timeout, subsequent timeouts occur with much greater frequency -- making this multi-GB download still an impracticality when using -net tap. The flood ping is not killing the network connection, though it is interrupted by frequent messages: "Warning: time of day goes back (-23150us), taking countermeasures". (This is no the high end of the time variances shown; the smallest are on the scale of 120us). [btw -- Wind River? heh -- 'yall were The Great Enemy back when I was at MontaVista around 2000-2002 or so]
[Qemu-devel] Re: Network connections stalling (due to lost interrupts/ticks?)
Well, behavior with the patch applied is certainly different. The large download I'm running still times out; however, it is now able to resume without needing to bring the interface down and back up. However, after the first timeout, subsequent timeouts occur with much greater frequency -- still making this multi-GB download an impracticality when using -net tap. The flood ping is not killing the network connection, though it is interrupted by frequent messages: "Warning: time of day goes back (-23150us), taking countermeasures". (This is no the high end of the time variances shown; the smallest are on the scale of 120us
[Qemu-devel] Re: Network connections stalling
This appears to only happen with -net tap; I cannot reproduce the issue with -net user.
[Qemu-devel] Re: Network connections stalling
This loss of connectivity is still happening; at least within my environment, it's quite reproducible. While I've eliminated the message about being unable to set the RTC to 1024Hz by recompiling my host kernel without CONFIG_HPET_RTC_IRQ, the host's kernel is frequently complaining "rtc: lost some interrupts at 1024Hz". I'm using tap-based networking (-net nic -net tap,ifname=tap0,script=./tap0-start), where tap0 is bridged to my local ethernet device, and outgoing network traffic from the qemu instance is visible if I monitor traffic on the bridge. Indeed, external responses to such traffic (ie. ARP responses) are visible on the bridge, but evidently not to the virtual machine: the TX counter rises when I try to ping the outside world, but the RX counter does not. Resetting the device (ifconfig eth0 down; ifconfig eth0 up) brings it back alive -- but this isn't an action which can trivially be slotted into a trivial, single-threaded install script. These same scripts have been tested on real hardware, and have not turned up this issue. Certainly, a race condition unrelated to qemu is possible, but I'd appreciate any insight 'yall can provide. Thank you!
[Qemu-devel] Re: Network connections stalling (due to lost interrupts/ticks?)
Charles Duffy wrote:
> There's a warning on startup that the system can't set a 1024Hz timer,
> which persists even after I set /proc/sys/dev/rtc/max-user-freq to 1024,
> and I occasionally get warnings at runtime ("Your time source seems to
> be instable or some driver is hogging interrupts").
This was happening because my host kernel was compiled with
CONFIG_HPET_RTC_IRQ=y. I've disabled this option, recompiled and
rebooted, and it resolved the RTC warning (and apparently, the unstable
time source messages) -- but my network connections are still stalling.
[Qemu-devel] Network connections stalling (due to lost interrupts/ticks?)
I'm trying to use qemu to test an install process which involves quite a
bit of downloading. Everything starts up fine (using either ne2k_pci or
rtl8139 hardware), but the multi-GB download typically stalls out about
100-400MB in. Is there anything I can do to prevent this?
There's a warning on startup that the system can't set a 1024Hz timer,
which persists even after I set /proc/sys/dev/rtc/max-user-freq to 1024,
and I occasionally get warnings at runtime ("Your time source seems to
be instable or some driver is hogging interrupts").
[Qemu-devel] etherboot support in x86_64 mode?
I notice that the "-boot n" etherboot support doesn't appear to work when emulating x86_64 hardware (invocation as qemu-system-x86_64). Is this intentional? A known issue?
