Subject: Re: #32287 Processes hang in "mclpl" - feedback
To: None <email@example.com>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 08/25/2006 16:39:39
In article <20060825023419.GW9268@canolog.ninthwonder.com>,
Allen Briggs <email@example.com> 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...