[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5570B0B2.5080908@fastly.com>
Date: Thu, 04 Jun 2015 13:10:26 -0700
From: Grant Zhang <gzhang@...tly.com>
To: Martin KaFai Lau <kafai@...com>
CC: netdev <netdev@...r.kernel.org>,
Neal Cardwell <ncardwell@...gle.com>,
Yuchung Cheng <ycheng@...gle.com>,
Eric Dumazet <edumazet@...gle.com>,
Kernel Team <kernel-team@...com>
Subject: Re: Recurring trace from tcp_fragment()
Hi Martin,
Thank you! My net.ipv4.tcp_mtu_probing is 1. After turning it off, the
WARN_ON stack is gone.
Could you elaborate a bit on why this setting relates to the WARN_ON
trace? And what are the pros/cons for disabling mtu_probing?
Thanks,
Grant
On 6/4/15 12:38 PM, Martin KaFai Lau wrote:
> Hi Grant,
>
> On Thu, Jun 04, 2015 at 09:35:04AM -0700, Grant Zhang wrote:
>> Hi Neal,
>>
>> Unfortunately with the patch we still see the same stack trace.
>> Attached is the TcpExtTCPSACKReneging with the patch, captured with
>> 60 seconds interval. Its value is incremented at an similar speed as
>> before, about 30/minute.
>>
>> If you want to collect any other data, please feel free to let me know.
>>
>
> We are also seeing similar WARN_ON stack in our kernel 4.0 testing.
>
> What is your net.ipv4.tcp_mtu_probing setting? I am currently testing some
> code changes and waiting for some more data. If it is 1 or 2,
> can you help to check whether turning it off (by setting it to 0) will stop the
> WARN_ON or not in your environment? Note that after setting it to 0, you
> may need to wait for a while (like a few mins) for the existing probing
> activities to quiet down before observing the WARN_ON output.
>
> Thanks,
> --Martin
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists