From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
To: Cedric Le Goater <legoater@free.fr>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Netdev <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>
Subject: Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
Date: Sat, 29 Sep 2007 23:49:30 +0300 (EEST) [thread overview]
Message-ID: <Pine.LNX.4.64.0709292333480.8339@kivilampi-30.cs.helsinki.fi> (raw)
In-Reply-To: <46FE6751.3050205@free.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2047 bytes --]
On Sat, 29 Sep 2007, Cedric Le Goater wrote:
> Ilpo Järvinen wrote:
> > On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
> >> On Fri, 28 Sep 2007, Cedric Le Goater wrote:
> >>
> >>> I just found that warning in my logs. It seems that it's been
> >>> happening since rc7-mm1 at least.
> >>>
> >>> WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 tcp_fastretrans_alert()
> >>>
> >>> Call Trace:
> >>> <IRQ> [<ffffffff8040fdc3>] tcp_ack+0xcd6/0x1894
> >>> ...snip...
> >> ...Thanks for the report, I'll have look what could still break
> >> fackets_out...
> >
> > I think this one is now clear to me, tcp_fragment/collapse adjusts
> > fackets_out (incorrectly) also for reno flow when there were some dupACKs
> > that made sacked_out != 0. Could you please try if patch below proves all
> > them to be of non-SACK origin... In case that's true, it's rather
> > harmless, I'll send a fix on Monday or so (this would anyway be needed)...
> > If you find out that them occur with SACK enabled flow, that would be
> > more interesting and requires more digging...
>
> I'm trying now to reproduce this WARNING.
>
> It seems that the n/w behaves differently during the week ends. Probably
> taking a break.
Thanks.
Of course there are other means too to determine if TCP flows do negotiate
SACK enabled or not. Depending on your test case (which is fully unknown
to me) they may or may not be usable... At least the value of tcp_sack
sysctl on both systems or tcpdump catching SYN packets should give that
detail. ...If you know to which hosts TCP could be connected (and active)
to, while the WARNING triggers, it's really easy to test what is being
negotiated as it's unlikely to change at short notice and any TCP flow to
that host will get us the same information though the WARNING would not be
triggered with it at this time. Obviously if at least one of the remotes
is not known or the set ends up being mixture of reno and SACK flows, then
we'll just have to wait and see which fish we get...
--
i.
next prev parent reply other threads:[~2007-09-29 20:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070927022220.c76a7a6e.akpm@linux-foundation.org>
2007-09-27 10:52 ` 2.6.23-rc8-mm2 - drivers/net/ibm_newemac/mal - broken Kamalesh Babulal
2007-09-28 15:42 ` 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING Cedric Le Goater
2007-09-28 19:10 ` Ilpo Järvinen
2007-09-29 12:44 ` Ilpo Järvinen
2007-09-29 14:55 ` Cedric Le Goater
2007-09-29 20:49 ` Ilpo Järvinen [this message]
2007-10-01 9:26 ` Cedric Le Goater
2007-10-02 10:26 ` Ilpo Järvinen
2007-10-02 20:06 ` Ilpo Järvinen
2007-10-02 21:48 ` Ilpo Järvinen
2007-09-28 16:30 ` /proc/net/ bad hard links count [Was: 2.6.23-rc8-mm2] Jiri Slaby
2007-09-28 17:03 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0709292333480.8339@kivilampi-30.cs.helsinki.fi \
--to=ilpo.jarvinen@helsinki.fi \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=legoater@free.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).