On 26/11/2011 05:23, Lawrence Stewart 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 wh
On 11/26/11 16:23, Lawrence Stewart 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
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,
be
Hi George,
On 11/27/11 03:16, George Mitchell wrote:
On 11/26/11 00:23, Lawrence Stewart wrote:
[...]
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/m
Hi Jeremy,
On 11/26/11 18:56, Jeremy Chadwick wrote:
On Sat, Nov 26, 2011 at 12:49:24AM -0600, Kris Bauer wrote:
On Fri, Nov 25, 2011 at 11:23 PM, Lawrence Stewartwrote:
On 11/25/11 13:01, Lawrence Stewart wrote:
[snip]
Thanks Kris, Raul and Stefan for the reports, I'll look into this.
On 11/26/11 02:56, Jeremy Chadwick wrote:
[...]
This entire situation leads me to believe very few people are doing
quality testing of RELENG_9, yet we're already into 9.0-RC2. Please
don't tell me "that's exactly why you should be running RELENG_9!"; that
is completely backwards and I refuse to
On 11/26/11 00:23, Lawrence Stewart wrote:
[...]
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
[...]
> 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 hea
On Sat, Nov 26, 2011 at 5:30 AM, Raul wrote:
> El 26/11/2011 6:23, Lawrence Stewart escribió:
>
> ...
>
>> 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
>>
>>
>
El 26/11/2011 6:23, Lawrence Stewart escribió:
...
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
On Fri, Nov 25, 2011 at 11:56:47PM -0800, Jeremy Chadwick wrote:
> On Sat, Nov 26, 2011 at 12:49:24AM -0600, Kris Bauer wrote:
> > On Fri, Nov 25, 2011 at 11:23 PM, Lawrence Stewart
> > wrote:
> >
> > > On 11/25/11 13:01, Lawrence Stewart wrote:
> > >
> > >> On 11/24/11 18:02, Kris Bauer wrote:
>
On Sat, Nov 26, 2011 at 12:49:24AM -0600, Kris Bauer wrote:
> On Fri, Nov 25, 2011 at 11:23 PM, Lawrence Stewart
> 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
On Fri, Nov 25, 2011 at 11:23 PM, Lawrence Stewart 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 consta
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
On Fri, Nov 25, 2011 at 01:05:06PM -0500, George Mitchell wrote:
> On 11/24/11 21:00, Jeremy Chadwick wrote:
> >[...]
> >If none of this solves the problem, then I consider this a priority 0
> >blocker (read: "all hands on deck") issue with the IP stack in FreeBSD
> >9.x and will need immediate att
George Mitchell wrote:
> On 11/24/11 21:00, Jeremy Chadwick wrote:
> >[...]
> > If none of this solves the problem, then I consider this a priority
> > 0
> > blocker (read: "all hands on deck") issue with the IP stack in
> > FreeBSD
> > 9.x and will need immediate attention.
> >
> > I would strongl
On 11/24/11 21:00, Jeremy Chadwick wrote:
[...]
If none of this solves the problem, then I consider this a priority 0
blocker (read: "all hands on deck") issue with the IP stack in FreeBSD
9.x and will need immediate attention.
I would strongly recommend a developer or clueful end-user begin
tra
El 24/11/2011 23:06, Stefan Bethke escribió:
[]
> I regularly copy large files off my Tivo trans-atlantic (125ms RTT),
> and TCP connections currently stall after about 500 megs, never
> recovering. I suspect this is connected, as it started immediately
> after upgrading the machine to 9-sta
Am 25.11.2011 um 00:35 schrieb Adrian Chadd:
> Have you tried disabling the tcp offload features of your NIC?
I'm using my em0 as a VLAN trunk, and I'm under the impression that that
disables all the hardware assists in the controller. Also, the LAN vlan is
bridged via OpenVPN and tap, making
El 25/11/2011 0:35, Adrian Chadd escribió:
Have you tried disabling the tcp offload features of your NIC?
In my case, there is no tcp on the ethernet interface.
It is pppoe (mpd / netgraph) so no fancy hardware acceleration there.
[...]
%ifconfig ng0 | head -n1
ng0: flags=88d1 metric 0
mtu 1
On Thu, Nov 24, 2011 at 10:20 PM, Lawrence Stewart wrote:
> On 11/25/11 14:19, Kris Bauer wrote:
>
>> On Thu, Nov 24, 2011 at 8:00 PM, Jeremy Chadwick
>> wrote:
>>
>> On Thu, Nov 24, 2011 at 07:13:39PM -0600, Kris Bauer wrote:
>>>
On Thu, Nov 24, 2011 at 5:35 PM, Adrian Chadd
>>> wrote:
On 11/25/11 14:19, Kris Bauer wrote:
On Thu, Nov 24, 2011 at 8:00 PM, Jeremy Chadwick
wrote:
On Thu, Nov 24, 2011 at 07:13:39PM -0600, Kris Bauer wrote:
On Thu, Nov 24, 2011 at 5:35 PM, Adrian Chadd
wrote:
Have you tried disabling the tcp offload features of your NIC?
Adrian
To test t
On Thu, Nov 24, 2011 at 8:00 PM, Jeremy Chadwick
wrote:
> On Thu, Nov 24, 2011 at 07:13:39PM -0600, Kris Bauer wrote:
> > On Thu, Nov 24, 2011 at 5:35 PM, Adrian Chadd
> wrote:
> >
> > > Have you tried disabling the tcp offload features of your NIC?
> > >
> > >
> > > Adrian
> > >
> >
> > To test
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
On Thu, Nov 24, 2011 at 07:13:39PM -0600, Kris Bauer wrote:
> On Thu, Nov 24, 2011 at 5:35 PM, Adrian Chadd wrote:
>
> > Have you tried disabling the tcp offload features of your NIC?
> >
> >
> > Adrian
> >
>
> To test this, I added net.inet.tcp.tso=0 to sysctl.conf and restarted the
> box; it d
On Thu, Nov 24, 2011 at 5:35 PM, Adrian Chadd wrote:
> Have you tried disabling the tcp offload features of your NIC?
>
>
> Adrian
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscrib
Have you tried disabling the tcp offload features of your NIC?
Adrian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On Thu, Nov 24, 2011 at 4:06 PM, Stefan Bethke wrote:
> Am 24.11.2011 um 21:30 schrieb Kris Bauer:
>
> > On Thu, Nov 24, 2011 at 1:20 PM, Raul wrote:
> >
> > I am seeing the same sorts of things in netstat & vmstat:
> >
> > # netstat -s -p tcp |grep mem
> > 742935 discarded due to memory problem
Am 24.11.2011 um 21:30 schrieb Kris Bauer:
> On Thu, Nov 24, 2011 at 1:20 PM, Raul wrote:
>
> I am seeing the same sorts of things in netstat & vmstat:
>
> # netstat -s -p tcp |grep mem
> 742935 discarded due to memory problems
>
> # vmstat -z |grep tcpreass
> tcpreass: 40, 16464, 16340, 124,
On Thu, Nov 24, 2011 at 1:20 PM, Raul wrote:
> El 24/11/2011 17:07, kerbzo escribió:
>
>
> I 'm experiencing a similar issue but I don't know if mine could be
>> considered normal behaviour: even if net.inet.tcp.reass.curesegments
>> is set to 1680 and does not icrease, the output of vmstat -z s
El 24/11/2011 17:07, kerbzo escribió:
I 'm experiencing a similar issue but I don't know if mine could be
considered normal behaviour: even if net.inet.tcp.reass.curesegments
is set to 1680 and does not icrease, the output of vmstat -z shows a
high tcpreass fail value that I don't remember in pr
On Thu, Nov 24, 2011 at 10:33 AM, Ivan Voras wrote:
> On 24.11.2011. 8: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 nom
On 24.11.2011. 8: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 wit
Hi,
I 'm experiencing a similar issue but I don't know if mine could be
considered normal behaviour: even if net.inet.tcp.reass.curesegments
is set to 1680 and does not icrease, the output of vmstat -z shows a
high tcpreass fail value that I don't remember in previous (8-STABLE)
builds:
ITEM
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.re
35 matches
Mail list logo
