> The system is Kanotix-2005-4
> Qemu-0.8.0
> Vde-1.5.9
>
> I setup the bridge and add interface tun0 to the bridge
> (have done it before correctly)
>
> but
>
> /usr/bin/vdeqemu -hda disk-image -m256 -localtime -net vde -net nic,macaddr=5
> 4:52:00:12:34:62
>
> reports error:
> qemu: invalid o
"Frank J. Beckmann" <[EMAIL PROTECTED]> wrote:
>
> qemu-0.8.1_1 with kqemu-kmod-1.3.0.p9 on FreeBSD 6.1-RELEASE i386 freezes
> after less than one hour runtime when more than one qemu is running. If only
> one qemu is running everything works fine. When more than one qemu runs none
> of them c
First, thanks to Fabrice for releasing a new kqemu and
Juergen Lock for a prompt freebsd port update! I did some
testing and have the following to report:
The good news:
- plan 9 works with kernel-kqemu and user-kqemu.
- user mode time in user/kernel kqemu mode is 1/3 of
-no-kqemu case for plan
The below patch avoids allocating space in the qcow image
format when a block of zeroes is being written. No attempt
is made to free up space if a previously written block of
nonzero data is being overwritten with zeroes. This patch
makes a big difference in space use for cases where the s/w
want
My personal opinion:
Discussions of the GPL are like the bird 'flu -- any time
anyone offers any program for free and there is a
list/newsgroup about it, we know some "bird" will get the GPL
discussion 'flu. This is inevitable but we can't seem to
avoid it. And everyone who gets it, starts throw
> I have never tied openbsd, but I have run NetBsd and Plan9(4th edition)
> under Qemu .8.0 with kqemu in windows. You may have to not use kqemu to
> install, i seem to remember doing that. Once installed though it works
> fine. Also I had to turn hyperthreading off. I have a P4 with 1gb of
>
The three I am aware of are: openbsd, netbsd & plan9. They
work fine with -no-kqemu flag. This is under freebsd but
I believe the same thing happens under linux.
The easiest test case may be plan 9 it seems to dies very
early. Download the plan9 .iso from one of
http://www.tip9ug.jp/mirror/
I just directly give a .iso as cdrom as in
qemu -cdrom foo.iso -boot d ins37.img
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Here is what I have learned so far w.r.t. freebsd. Hope this
helps people running qemu+freebsd.
Qemu versions: qemu-0.7.0s.20050717 & qemu-0.7.1 [1] + kqemu
Host: freebsd-5.x freebsd-6, freebsd-7-current [2]
Processors: P4, AthlonXP, P4 HT[3]
VMs[4]: freebsd-4.x, freebsd-5.x, dragonfly (latest)
> DHCP is Ethernet broadcast based, not IP.
Not that it matters in this case but strictly speaking DHCP
is an IP protocol, using UDP as its transport and the request
goes to IP broadcast address of 255.255.255.255.
> You could also run a local DHCP server on tap0, configured with the
> address s
Lock writes:
> Is kqemu and the freebsd wrapper smp aware? I just saw this panic
> report again,
> http://lists.freebsd.org/pipermail/freebsd-current/2005-May/050161.html
> and noticed it apparently happened with an smp kernel.
My guess is
.d_flags = D_NEEDGIANT,
needs to be adde
> I am using kqemu and qemu built from May 2 snapshot if that
> matters. This was a stock 5.4-RELEASE complied locallly
> with
>
> makeoptionsDEBUG=-g
>
> added the kernel config file. The host was also running 5.4
> but that should not matter.
Ugh... Should've done a diff with GENER
Hmm... I've used qemu a bit to debug the kernel. Even used
it to debug a loadable module. Here is what I did:
# qemu -s img
# cd
# gdb kernel.debug
(gdb) target remote localhost:1234
...
(gdb) l kldload
739 /*
740 * MPSAFE
741 */
742 int
743 kldload(struct thread *td, stru
13 matches
Mail list logo
