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, m
[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
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
This appears to only happen with -net tap; I cannot reproduce the issue
with -net user.
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
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 d
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 o
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?
