Thank you very much, Henrik,
based on your reply I've found the relevant linux kernel TUN/TAP problem
description
in http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.11-rc2
and was able to workaround the problem in my case with the small patch:
--- qemu-0.7.0/vl.c.orig 2005-04-28 00:52:05.000000000 +0400
+++ qemu-0.7.0/vl.c 2005-07-12 13:14:11.583204352 +0400
@@ -1622,7 +1622,7 @@
return -1;
}
memset(&ifr, 0, sizeof(ifr));
- ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
+ ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_ONE_QUEUE;
pstrcpy(ifr.ifr_name, IFNAMSIZ, "tun%d");
ret = ioctl(fd, TUNSETIFF, (void *) &ifr);
if (ret != 0) {
May be the problem deserves mentioning in some qemu docs?
Regards
Vitaly
On Tue, Jul 12, 2005 at 03:09:43AM +0200, Henrik Nordstrom wrote:
> On Tue, 12 Jul 2005, Vitaly Belostotsky wrote:
>
> >I've encountered some network related bug when using qemu with tun
> >and I'm willing to debug it but could you please provide some help.
>
> you may want to try upgrading to the host kernel to 2.6.12. Had quite a
> bit of issues with tun devices "hanging" in earlier Linux-2.6 versions,
> but after I switched to a Fedora Core 4 host running Linux-2.6.12 things
> seems much more stable.
>
> My diagnostics at the time indicated some flow control problem within the
> host kernle tun driver, making the driver stall and not deliver packets to
> the application (qemu). Your findings seems to indicate very similar
> result.
>
> Regards
> Henrik
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
