Re: Help! Network issue with freebsd + Xen
On Wed, 26 Jan 2011, Alex wrote: > I am having an issue with high network interface collisions when running > freebsd under XEN (I am using freebsd as my OS for a VPS). [..] > whether they have seen the same issue or know what may be causing it. I can confirm seeing it here also, you are not alone: $ netstat -i NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll re01500 00:16:3e:08:b4:c7 21150230 0 0 4101045 0 4019323 [..] I had not noticed it before. I am not encountering any packet loss or other networking problems. No idea about the reason. This is on FreeBSD 8.1-RELEASE-p2 amd64 with GENERIC kernel. -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Help! Network issue with freebsd + Xen
Hi guys, I am having an issue with high network interface collisions when running freebsd under XEN (I am using freebsd as my OS for a VPS). I have filed a PR at http://www.freebsd.org/cgi/query-pr.cgi?pr=154236 and have had some discussion with the driver maintainer, we're both at a loss as to what the issue is, perhaps someone here could take a look at it and see whether they have seen the same issue or know what may be causing it. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: I have a problem with iSCSI on AMD64 Xen HVM
On Tue, 25 Jan 2011, Luke Marsden wrote: > On Tue, 2011-01-25 at 14:35 +, Janne Snabb wrote: > > I would guestimate that either "max" should be higher than what it > > currently is (5) or the check which produces the error might be > > unneeded. > > In my tests commenting out that check entirely works fine. It also appears that before SVN r181945 (2008-08-21 by kmacy) "max" was 24, so it was much less likely to hit the (possibly unneeded) "if (frags > max)" check limit: > int max = 24 /* MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD) */; I do not understand from the commit message why it was changed to 5. (I wish there was a bit more comments in the non-obvious parts of the code. Now it is difficult for a FreeBSD/Xen PV newbie to work on it without intimate knowledge of the history of the odd bits of the code. It clearly needs more care than what it is being given now. Things like the "do something useful" panic also indicate that there is no more than few people who actually play with and try out the code currently.) -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: I have a problem with iSCSI on AMD64 Xen HVM
On Tue, 2011-01-25 at 14:35 +, Janne Snabb wrote: > I would guestimate that either "max" should be higher than what it > currently is (5) or the check which produces the error might be > unneeded. In my tests commenting out that check entirely works fine. http://www.hybrid-cluster.com/blog/2010/11/running-freebsd-8-1-as-a-xen-hvm-domu-on-flexiant/ -- Best Regards, Luke Marsden CTO, Hybrid Logic Ltd. Web: http://www.hybrid-cluster.com/ Hybrid Web Cluster - cloud web hosting Phone: +441172232002 / +16179496062 ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: I have a problem with iSCSI on AMD64 Xen HVM
On Mon, 24 Jan 2011, Grzegorz Rybicki wrote:
> xennet_get_responses: too many frags 11 > max 5
[..]
The following in sys/dev/xen/netfront/netfront.c xennet_get_responses()
looks a little bit suspicious:
> int max = 5 /* MAX_TX_REQ_FRAGS + (rx->status <= RX_COPY_THRESHOLD) */;
...together with the check at the end of the function (the only place
where "max" is used) which produces the error message you see:
> if (unlikely(frags > max)) {
> if (net_ratelimit())
> WPRINTK("Too many frags\n");
> printf("%s: too many frags %d > max %d\n", __func__, frags,
> max);
> err = E2BIG;
> }
MAX_TX_REQ_FRAGS is defined as follows in the same file:
> #define MAX_TX_REQ_FRAGS (65536 / PAGE_SIZE + 2)
...which produces already 18. Where does this "max = 5" come from?
Either "max" is wrong or I do not understand the comment on the
line where it is defined.
There are some interesting and probably related comments in the
same file about the Linux netback driver's lacking capabilities of
handling many fragments. But why do we care about that when receiving?
I would guestimate that either "max" should be higher than what it
currently is (5) or the check which produces the error might be
unneeded.
--
Janne Snabb / EPIPE Communications
sn...@epipe.com - http://epipe.com/
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Issue with non-PAE enable i386 xen guest
On Mon, 24 Jan 2011, karim.allah.ah...@gmail.com wrote: > Is the current non-PAE xen guest implementation broke intentionally, or is > this a merge issue or something ? According to http://wiki.freebsd.org/FreeBSD/Xen it is not supposed to work: "Para-virtualized i386 kernels require options PAE to be included in the kernel configuration." -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
