Date: Wed, 8 Oct 2003 13:17:55 +0100 From: Bruce M Simpson <bms@spc.org> To: Peter Bozarov <peter.bozarov@moniforce.com> Cc: freebsd-net@freebsd.org Subject: Re: Recovery from mbuf cluster exhaustion Message-ID: <20031008121755.GA83114@saboteur.dek.spc.org> In-Reply-To: <3F83F37A.7020908@moniforce.com> References: <3F83E2A7.8070209@moniforce.com> <20031008101733.GI6524@saboteur.dek.spc.org> <3F83F37A.7020908@moniforce.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 08, 2003 at 01:22:34PM +0200, Peter Bozarov wrote:
> I'm using 4.7. I have three interfaces, rl0, xl0, and xl1.
Support for 4.7 is very limited as we transition to 4.9, please be
prepared to upgrade the box. Bear in mind we commit fixes for problems
to HEAD first except in those cases where RELENG_4 is more appropriate.
> The rl0 interface is a RealTek 8139 10/100BaseTX, the
> xl* are two 3Com 3c905-TX Fast Etherlink XL cards.
> This is what my routing tables look like.
[snip]
I spot only one possible inconsistency. (Well, two if you count the
use of subnet-zero, but this is academic as nearly everybody follows
RFC 950 these days).
Did you add the 10.2.1.68 route manually? Note that there is code
in if_ethersubr.c which should loopback a copy of a packet sent on an
IFF_SIMPLEX interface automatically, so it shouldn't be required.
For example, on my laptop:
192.168.1.68 00:04:76:5e:ec:7d UHLW 0 2 lo0
This route is created automatically by arp_rtrequest(). The RTF_WASCLONED
(W) flag tells us this. Because ether_output() is calling if_simloop() to
loopback the packets, the RTF_LLINFO (L) flag gets ignored.
Try removing this route and see what happens.
> My machine serves as a bridge between the 10.0.0.0/24 (xl0) and
> the 10.2.1.0/24 networks (rl0). xl1 is not being used. I've made
> a tcpdump of machines on the 10.2.1.0/24 network communicating
> with the internet. Now, on the 10.0.0.0/24, I have a sniffer. I'm
> trying to test the program by injecting the tcpdump file into
> the 10.0.0.0/24 network. Apparently, since some of the outgoing
> traffic on xl0 is originated on or is meant for the localhost
> (10.2.1.68) the xl0 driver starts buffering/passing those segments
> to the kernel (xl0 is in promiscuous mode).
^^^^^^^^^^^^^^^^^^^^^^^^^^
Are you using the bridging code to do this?
If so, can you post the bridging configuration?
I'm not at all familiar with the bridging code, but I am giving it
a read just now, hopefully Luigi will step in.
> How do I cause the driver (or whatever it is) that's hogging the
> clusters to relinquish them?
Unfortunately it doesn't quite work that way... you are exercising
a leak somewhere and it needs to be tracked down. You should collate
all the information as we track this thread and prepare to submit a PR.
BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031008121755.GA83114>