[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] FreeBSD qemu-devel 0.12.0-rc2 port update available for tes
From: |
Juergen Lock |
Subject: |
[Qemu-devel] FreeBSD qemu-devel 0.12.0-rc2 port update available for testing |
Date: |
Mon, 14 Dec 2009 23:06:48 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
Hi!
I updated my git head snapshot qemu-devel port update to 0.12.0-rc2
today (that was just announced:
http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg01514.html
- the Subject says rc1 but in fact its rc2) so people can test that
version on FreeBSD more easily:
http://people.freebsd.org/~nox/qemu/qemu-devel-0.12.0-rc2.patch
resp.
http://people.freebsd.org/~nox/qemu/qemu-devel-0.12.0-rc2.shar
(As mentioned before 0.11 was the last qemu branch that supported kqemu
so this is probably only interesting for those FreeBSD users that want
to emulate non-x86 guests or when performance doesn't matter. But the
others are probably already moving to virtualbox now anyway... :)
I have updated the FreeBSD pcap patch just enough so that it still runs
(it probably will never be committed upstream anyway since Linux pcap
doesn't have BIOCFEEDBACK i.e. can't talk to the host, only to other
machines on the network) and I still see this weird issue here that
packets `sometimes' are only processed with a delay (when the nic is
otherwise idle?), i.e. pinging the host or another box on the lan with e.g.
-i5 from the guest sees many packets with >5000ms roundtrip time. Can
anyone else reproduce this or is that `just me'? This is on stable/8
now (amd64) but it also happened with earlier versions, tested with
qemu 8.0-RELEASE-i386-dvd1.iso -m 256 -net nic,model=e1000 -net
pcap,ifname=em0
via fixit->cdrom. And this is most likely pcap related, I don't see
anything like it with tap networking.
Cheers,
Juergen
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] FreeBSD qemu-devel 0.12.0-rc2 port update available for testing,
Juergen Lock <=