In article <20060825023419.GW9268@canolog.ninthwonder.com>,
Allen Briggs  <briggs@netbsd.org> wrote:
>On Thu, Aug 24, 2006 at 11:00:13PM +0200, Pavel Cahyna wrote:
>> [ please reply to tech-net@ ]
>> On Thu, Aug 24, 2006 at 12:42:26AM +0000, Christos Zoulas wrote:
>> > So we see from the data that you have the same problem like I do. We are
>> > leaking mbufs in the tcp recv. I've been reading the code, but I have not
>> > found a problem...
>> 
>> recv? don't you mean transmit?
>> 
>> I would try compiling and testing a kernel with options SOSEND_NO_LOAN.
>
>I have seen a case where a network interface reset leaked any
>outstanding mbufs queued on that interface.  That's a driver-
>specific issue, though, and I haven't checked all of the drivers
>in the tree to see if any have that error.  Most are, I think, fine
>in this area.  I just checked fxp(4), wm(4), bge(4), and bce(4)
>(since I use all of those ;-), and they all seem fine--they unload
>the dmamap and m_freem() in xxx_stop() or similar.
>

But in my case nobody calls xxx_stop() or similar (i.e. nobody is typing
ifconfig up/down). My driver is gem(4) if that makes a difference...

christos