Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Nov 2011 22:07:17 +0100
From:      kerbzo <kerbzo@gmail.com>
To:        Lawrence Stewart <lstewart@freebsd.org>
Cc:        freebsd-stable@freebsd.org, stb@lassitu.de, raul@turing.b2n.org, Kris Bauer <kristoph.bauer@gmail.com>, george+freebsd@m5p.com, FreeBSD Release Engineering Team <re@freebsd.org>, freebsd@jdc.parodius.com
Subject:   Re: TCP Reassembly Issues
Message-ID:  <CABLqceRRFq%2BqQzac3Gkct3JFOcJzXhAWFqUGc%2BM%2BDO5bcgC3zQ@mail.gmail.com>
In-Reply-To: <4ED077BF.10205@freebsd.org>
References:  <CAPNZ-Wq38=F3o2hYuYF_unBj3SZQ52XhVhdcwQ8PE_vU9xc2YA@mail.gmail.com> <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

this patch works for me, also.
Reass counter now does not increase ( tcpreass:                40,
1680,      21,     399,  572562,   0,   0 ) and a severe network
performance issue of netatalk and afpd, used as a "Time Capsule"
server for mac os x,  seems now disappeared.
Really thank you,

best regards,

On Sat, Nov 26, 2011 at 6:23 AM, Lawrence Stewart <lstewart@freebsd.org> wrote:
> On 11/25/11 13:01, Lawrence Stewart wrote:
>>
>> On 11/24/11 18:02, Kris Bauer wrote:
>>>
>>> Hello,
>>>
>>> I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852
>>> where the
>>> net.inet.tcp.reass.curesegments value is constantly increasing (and not
>>> descreasing when there is nominal traffic with the box). It is causing
>>> tcp
>>> slowdowns as described with kern/155407:
>>>
>>> Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session
>>> (for
>>> this socket and any other socket waiting for retransmited packets). After
>>> exhausted net.inet.tcp.reass.maxsegments allocation new entry in
>>> tcp_reass
>>> failed (for this socket and any other socket waiting for retransmited
>>> packets).
>>>
>>> I have increased the reass.maxsegments value to 16384 to temporarily
>>> avoid
>>> the problem, but the cursegments number keeps rising and it seems it will
>>> occur again.
>>>
>>> Is this an issue that anyone else has seen? I can provide more
>>> information
>>> if need be.
>>
>> Thanks Kris, Raul and Stefan for the reports, I'll look into this.
>
> I think I've got it - a stupid 1 line logic bug. My apologies for missing it
> when I reviewed the patch which introduced the bug (patch was committed to
> head as r226113, MFCed to stable/9 as r226228).
>
> Due to some miscommunication, the initial patch was committed to and MFCed
> from head much later than it should have been in the 9.0 release cycle and
> instead of being included in the BETAs, didn't make it in until 9.0-RC1 I
> believe i.e. only RC1 and RC2 should be experiencing the issue.
>
> Could those who have reported the bug and are able to recompile their kernel
> to test a patch please try the following and report back to the list:
>
> http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak_10.x.r227986.patch
>
> The patch is against head r227986 but will apply and work correctly for 9.0
> as well.
>
> Cheers,
> Lawrence
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABLqceRRFq%2BqQzac3Gkct3JFOcJzXhAWFqUGc%2BM%2BDO5bcgC3zQ>