* [RFC][PATCH] Removal of FASTROUTE definition include/linux/if_packet.h
From: Rami Rosen @ 2007-08-02 9:23 UTC (permalink / raw)
To: netdev, linux-kernel
Hi,
It seems that PACKET_FASTROUTE definition should be removed due to that
fastroute is no longer supported.
Regards,
Rami Rosen
--
Signed-off-by: Rami Rosen <ramirose@gmail.com>
--- linux-2.6.23-rc1-clean/include/linux/if_packet.h 2007-05-03
12:07:59.000000000 +0300
+++ linux-2.6.23-rc1/include/linux/if_packet.h 2007-08-02
11:37:16.000000000 +0300
@@ -30,7 +30,6 @@ struct sockaddr_ll
#define PACKET_OUTGOING 4 /* Outgoing of any type */
/* These ones are invisible by user level */
#define PACKET_LOOPBACK 5 /* MC/BRD frame looped back */
-#define PACKET_FASTROUTE 6 /* Fastrouted frame */
/* Packet socket options */
^ permalink raw reply
* Re: TCP SACK issue, hung connection, tcpdump included
From: David Miller @ 2007-08-02 9:26 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: darryl-mailinglists, linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.64.0708021056560.8788@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Thu, 2 Aug 2007 12:23:23 +0300 (EEST)
> ...Seriously, somebody else than me is probably better in suggesting what
> could cause the discarding at the SERVER in this case. SNMP stuff Dave was
> asking could help, you can find them from /proc/net/{netstat,snmp}...
That will also tell us if TCP discarded the packet due to
timestamps tests or similar.
^ permalink raw reply
* Re: [RFC][PATCH] Removal of FASTROUTE definition include/linux/if_packet.h
From: David Miller @ 2007-08-02 9:26 UTC (permalink / raw)
To: ramirose; +Cc: netdev, linux-kernel
In-Reply-To: <eb3ff54b0708020223o521e89b9v3200e06ab296df12@mail.gmail.com>
From: "Rami Rosen" <ramirose@gmail.com>
Date: Thu, 2 Aug 2007 12:23:41 +0300
> Hi,
> It seems that PACKET_FASTROUTE definition should be removed due to that
> fastroute is no longer supported.
It's a value exported to userland, so removing it could
break application compilation, so we can't remove it.
^ permalink raw reply
* Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
From: Sam Ravnborg @ 2007-08-02 9:36 UTC (permalink / raw)
To: Matt Mackall
Cc: Jarek Poplawski, Gabriel C, Andrew Morton, linux-kernel, netdev,
jason.wessel, amitkale
In-Reply-To: <20070802020219.GM11166@waste.org>
> >
> > ...
> > endif # NETDEVICES
> >
> > config NETPOLL
> > depends on NETDEVICES
> > def_bool NETCONSOLE
> >
> > config NETPOLL_TRAP
> > bool "Netpoll traffic trapping"
> > default n
> > depends on NETPOLL
> >
> > config NET_POLL_CONTROLLER
> > def_bool NETPOLL
> > depends on NETPOLL
> >
> >
> > seems to select NET_POLL_CONTROLLER after selecting NETPOLL, but
> > still doesn't check for NETDEVICES dependency.
>
> That's odd. Adding Sam to the cc:.
select is evil....
select will by brute force set a symbol equal to 'y' without
visiting the dependencies.
So abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols (no promts anywhere)
and for symbols with no dependencies.
That will limit the suefullness but on the other hand avoid the illegal
configurations all over.
kconfig should one day warn about such things but I have not fel inclined
to dive into the matters hoping that Roman does one day.
Sam
^ permalink raw reply
* Re: strange tcp behavior
From: Evgeniy Polyakov @ 2007-08-02 9:55 UTC (permalink / raw)
To: john; +Cc: netdev
In-Reply-To: <56697.212.93.96.73.1186035546.squirrel@mail.screen.lv>
On Thu, Aug 02, 2007 at 09:19:06AM +0300, john@screen.lv (john@screen.lv) wrote:
> 1186035057.207629 127.0.0.1 -> 127.0.0.1 TCP 50000 > smtp [SYN]
> Seq=0 Len=0
> 1186035057.207632 127.0.0.1 -> 127.0.0.1 TCP smtp > 50000 [SYN, ACK]
> Seq=0 Ack=1 Win=32792 Len=0 MSS=16396
> 1186035057.207666 127.0.0.1 -> 127.0.0.1 TCP 50000 > smtp [ACK]
> Seq=1 Ack=1 Win=1500 Len=0
> 1186035057.207699 127.0.0.1 -> 127.0.0.1 SMTP Command: EHLO localhost
> 1186035057.207718 127.0.0.1 -> 127.0.0.1 TCP smtp > 50000 [ACK]
> Seq=1 Ack=17 Win=32792 Len=0
> 1186035057.207736 127.0.0.1 -> 127.0.0.1 TCP 50000 > smtp [RST]
> Seq=17 Len=0
> 1186035057.223934 127.0.0.1 -> 127.0.0.1 TCP 33787 > 50000 [RST,
> ACK] Seq=0 Ack=0 Win=32792 Len=0
>
> Can someone please comment as to why, tcp stack sends rst packet from the
> wrong source port in this situation.
Besides the fact, that test applications do not run if started not as
root, I got this:
13:51:12.180241 IP localhost.localdomain.50000 > localhost.localdomain.10250: S 906222067:906222067(0) win 1500
13:51:12.180279 IP localhost.localdomain.10250 > localhost.localdomain.50000: S 2011233747:2011233747(0) ack 906222068
win 32792 <mss 16396>
13:51:12.180293 IP localhost.localdomain.50000 > localhost.localdomain.10250: R 906222068:906222068(0) win 0
13:51:12.180320 IP localhost.localdomain.50000 > localhost.localdomain.10250: . ack 1 win 1500
13:51:12.180329 IP localhost.localdomain.10250 > localhost.localdomain.50000: R 2011233748:2011233748(0) win 0
13:51:12.180341 IP localhost.localdomain.50000 > localhost.localdomain.10250: P 1:17(16) ack 1 win 1500
13:51:12.180349 IP localhost.localdomain.10250 > localhost.localdomain.50000: R 2011233748:2011233748(0) win 0
13:51:12.180361 IP localhost.localdomain.50000 > localhost.localdomain.10250: R 906222084:906222084(0) win 1500
I.e. there is no bug in this session.
FC7 2.6.22.1-27.fc7 kernel.
Here is vanilla (with my patches, unrelated to the problem though)
2.6.22-rc5:
09:33:37.650279 IP localhost.50000 > localhost.10250: S 1326688203:1326688203(0) win 1500
09:33:37.664391 IP localhost.10250 > localhost.50000: S 3637551175:3637551175(0) ack 1326688204 win 32792 <mss 16396>
09:33:37.664417 IP localhost.50000 > localhost.10250: R 1326688204:1326688204(0) win 0
09:33:37.650451 IP localhost.50000 > localhost.10250: . ack 1 win 1500
09:33:37.650467 IP localhost.10250 > localhost.50000: R 3637551176:3637551176(0) win 0
09:33:37.650481 IP localhost.50000 > localhost.10250: P 1:17(16) ack 1 win 1500
09:33:37.650493 IP localhost.10250 > localhost.50000: R 3637551176:3637551176(0) win 0
09:33:37.650507 IP localhost.50000 > localhost.10250: R 1326688220:1326688220(0) win 1500
Is it possible that your tcpdump is screwed?
--
Evgeniy Polyakov
^ permalink raw reply
* Re: strange tcp behavior
From: Evgeniy Polyakov @ 2007-08-02 10:16 UTC (permalink / raw)
To: john; +Cc: netdev
In-Reply-To: <20070802095550.GA27226@2ka.mipt.ru>
On Thu, Aug 02, 2007 at 01:55:50PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:
> On Thu, Aug 02, 2007 at 09:19:06AM +0300, john@screen.lv (john@screen.lv) wrote:
> > 1186035057.207629 127.0.0.1 -> 127.0.0.1 TCP 50000 > smtp [SYN]
> > Seq=0 Len=0
> > 1186035057.207632 127.0.0.1 -> 127.0.0.1 TCP smtp > 50000 [SYN, ACK]
> > Seq=0 Ack=1 Win=32792 Len=0 MSS=16396
> > 1186035057.207666 127.0.0.1 -> 127.0.0.1 TCP 50000 > smtp [ACK]
> > Seq=1 Ack=1 Win=1500 Len=0
> > 1186035057.207699 127.0.0.1 -> 127.0.0.1 SMTP Command: EHLO localhost
> > 1186035057.207718 127.0.0.1 -> 127.0.0.1 TCP smtp > 50000 [ACK]
> > Seq=1 Ack=17 Win=32792 Len=0
> > 1186035057.207736 127.0.0.1 -> 127.0.0.1 TCP 50000 > smtp [RST]
> > Seq=17 Len=0
> > 1186035057.223934 127.0.0.1 -> 127.0.0.1 TCP 33787 > 50000 [RST,
> > ACK] Seq=0 Ack=0 Win=32792 Len=0
> >
> > Can someone please comment as to why, tcp stack sends rst packet from the
> > wrong source port in this situation.
>
> Besides the fact, that test applications do not run if started not as
> root, I got this:
And it actually does not initializes a session, since tird line below
shows RST, but not ack. The same with sendmail smtp server (i.e. 25 port
like in your server) and unmodified client.
Please provide application which can trigger the issue and I will help
to debug this issue. If it will help you to debug client, I can run
tcpdump on public server (say 194.85.82.65, please tell me your source
address) to collect dumps. Current code does not trigger the issue on my
machines (and works not like was intended by you). Ugh, and code really
looks horrible...
--
Evgeniy Polyakov
^ permalink raw reply
* Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
From: Satyam Sharma @ 2007-08-02 10:32 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Matt Mackall, Jarek Poplawski, Gabriel C, Andrew Morton,
linux-kernel, netdev, jason.wessel, amitkale
In-Reply-To: <20070802093659.GB27748@uranus.ravnborg.org>
Hi,
On Thu, 2 Aug 2007, Sam Ravnborg wrote:
> > >
> > > ...
> > > endif # NETDEVICES
> > >
> > > config NETPOLL
> > > depends on NETDEVICES
> > > def_bool NETCONSOLE
> > >
> > > config NETPOLL_TRAP
> > > bool "Netpoll traffic trapping"
> > > default n
> > > depends on NETPOLL
> > >
> > > config NET_POLL_CONTROLLER
> > > def_bool NETPOLL
> > > depends on NETPOLL
> > >
> > >
> > > seems to select NET_POLL_CONTROLLER after selecting NETPOLL, but
> > > still doesn't check for NETDEVICES dependency.
> >
> > That's odd. Adding Sam to the cc:.
I just noticed this thread, but I wonder what the fuss is all
about :-) Kconfig dependencies are easy, really -- any code that
pulls in code from elsewhere, must explicitly "depends on" it.
It is possible to use "select" as well, but could lead to breakages
as discussed to death on at least 64592 other threads on LKML already
and hence should only be used for library-like code that does not
have any dependencies itself.
> select is evil....
> select will by brute force set a symbol equal to 'y' without
> visiting the dependencies.
> So abusing select you are able to select a symbol FOO even
> if FOO depends on BAR that is not set.
>
> In general use select only for non-visible symbols (no promts anywhere)
> and for symbols with no dependencies.
> That will limit the suefullness but on the other hand avoid the illegal
> configurations all over.
The problem with using "depends on" is that your config symbol becomes
invisible unless the dependency has already been selected.
So, there's a workaround: make the ultimate config symbol itself depend
upon the grand-dependency (excuse the nomenclature) and just "select"
the immediate-parent-dependency, i.e. the following:
CONFIG_BAZ
...
CONFIG BAR
depends on BAZ
CONFIG_FOO
depends on BAZ
select BAR
is perfectly legal, and doesn't cause any build problems. Perhaps such a
solution makes sense here as well?
> kconfig should one day warn about such things but I have not fel inclined
> to dive into the matters hoping that Roman does one day.
Yup, I've wanted to do this myself, in fact I wanted to implement an idea
I had in mind ( http://lkml.org/lkml/2007/5/16/257 ) but for some reason
I tend to stay away from stuff in scripts/ :-)
Satyam
^ permalink raw reply
* Re: [PATCH 1/2] [TCP]: Also handle snd_una changes in tcp_cwnd_down
From: Ilpo Järvinen @ 2007-08-02 11:18 UTC (permalink / raw)
To: David Miller; +Cc: Netdev
In-Reply-To: <Pine.LNX.4.64.0708012054180.27657@kivilampi-30.cs.helsinki.fi>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1948 bytes --]
On Wed, 1 Aug 2007, Ilpo Järvinen wrote:
>
> tcp_cwnd_down must check for it too as it should be conservative
> in case of collapse stuff and also when receiver is trying to
> lie (though that wouldn't be very successful/useful anyway).
>
> Note:
> - Separated also is_dupack and do_lost in fast_retransalert
> * Much cleaner look-and-feel now
> * This time it really fixes cumulative ACK with many new
> SACK blocks recovery entry (I claimed this fixes with
> last patch but it wasn't). TCP will now call
> tcp_update_scoreboard regardless of is_dupack when
> in recovery as long as there is enough fackets_out.
> - Introduce FLAG_SND_UNA_ADVANCED
> * Some prior_snd_una arguments are unnecessary after it
> - Added helper FLAG_ANY_PROGRESS to avoid long FLAG...|FLAG...
> constructs
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> ---
>
> Dave, BEWARE, I wasn't able to do anything else but compile test
> because Linus' tree didn't seem to boot on the machine I was
> trying to test it... :-(
>
> I think that to stable version only a small part of this change
> is necessary, not the full changeset. That should keep stable
> folks much happier... :-) I'll soon put my reduced proposal to:
> http://www.cs.helsinki.fi/u/ijjarvin/patches/stable-0001.patch
> The other patch (DSACK) can go to stable as is.
I placed those two earlier sent bidir fixes and these two additional fixes
on top of 2.6.22 and was finally able to have them tested on a bootable
kernel (I had a boot failure on another machine too with 2.6.23-rc1
stuff). FACK&NewReno/bidir and FACK/unidir tested, time-seq graphs were
ok.
Dave, please put these two patches to net-2.6 to complete bidir fix
series. ...And please push to stable as well, take just the minimized
"fix" portion of this "[TCP]: Also handle snd_una changes in
tcp_cwnd_down" patch as I described above. Other cleanups in it can be
put just to net-2.6.
--
i.
^ permalink raw reply
* Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
From: Jarek Poplawski @ 2007-08-02 11:40 UTC (permalink / raw)
To: Satyam Sharma
Cc: Sam Ravnborg, Matt Mackall, Gabriel C, Andrew Morton,
linux-kernel, netdev, jason.wessel, amitkale
In-Reply-To: <alpine.LFD.0.999.0708021547420.8258@enigma.security.iitk.ac.in>
On Thu, Aug 02, 2007 at 04:02:21PM +0530, Satyam Sharma wrote:
> Hi,
>
>
> On Thu, 2 Aug 2007, Sam Ravnborg wrote:
>
> > > >
> > > > ...
> > > > endif # NETDEVICES
> > > >
> > > > config NETPOLL
> > > > depends on NETDEVICES
> > > > def_bool NETCONSOLE
> > > >
> > > > config NETPOLL_TRAP
> > > > bool "Netpoll traffic trapping"
> > > > default n
> > > > depends on NETPOLL
> > > >
> > > > config NET_POLL_CONTROLLER
> > > > def_bool NETPOLL
> > > > depends on NETPOLL
> > > >
> > > >
> > > > seems to select NET_POLL_CONTROLLER after selecting NETPOLL, but
> > > > still doesn't check for NETDEVICES dependency.
> > >
> > > That's odd. Adding Sam to the cc:.
>
> I just noticed this thread, but I wonder what the fuss is all
> about :-) Kconfig dependencies are easy, really -- any code that
> pulls in code from elsewhere, must explicitly "depends on" it.
> It is possible to use "select" as well, but could lead to breakages
> as discussed to death on at least 64592 other threads on LKML already
> and hence should only be used for library-like code that does not
> have any dependencies itself.
So, it seems at least one time not enough (or maybe it would be better
to write this 1 time only, but in Documentation/).
>
>
> > select is evil....
> > select will by brute force set a symbol equal to 'y' without
> > visiting the dependencies.
> > So abusing select you are able to select a symbol FOO even
> > if FOO depends on BAR that is not set.
> >
> > In general use select only for non-visible symbols (no promts anywhere)
> > and for symbols with no dependencies.
> > That will limit the suefullness but on the other hand avoid the illegal
> > configurations all over.
>
> The problem with using "depends on" is that your config symbol becomes
> invisible unless the dependency has already been selected.
>
> So, there's a workaround: make the ultimate config symbol itself depend
> upon the grand-dependency (excuse the nomenclature) and just "select"
> the immediate-parent-dependency, i.e. the following:
>
> CONFIG_BAZ
> ...
>
> CONFIG BAR
> depends on BAZ
>
> CONFIG_FOO
> depends on BAZ
> select BAR
>
> is perfectly legal, and doesn't cause any build problems. Perhaps such a
> solution makes sense here as well?
>
>
> > kconfig should one day warn about such things but I have not fel inclined
> > to dive into the matters hoping that Roman does one day.
>
> Yup, I've wanted to do this myself, in fact I wanted to implement an idea
> I had in mind ( http://lkml.org/lkml/2007/5/16/257 ) but for some reason
> I tend to stay away from stuff in scripts/ :-)
How often "common" developer has to make such decisions in Kconfig?
Probably no more than once per year. So, it's fair to blame anybody
for not reading lkml to find if there are some bugs or
recommendations before using apparently simple tool? I think there
is usually some README for such things (maybe in Documentation/)?
Thanks,
Jarek P.
PS: if it's so easy and it's enough to read only 64592 lkml messages,
I wonder why Andrew, who knows all lkml, and reads more messages per
hour, cared to remember mainly one short conclusion...
^ permalink raw reply
* Re: strange tcp behavior
From: Simon Arlott @ 2007-08-02 11:38 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: john, netdev
In-Reply-To: <20070802101655.GA14749@2ka.mipt.ru>
On Thu, August 2, 2007 11:16, Evgeniy Polyakov wrote:
> On Thu, Aug 02, 2007 at 01:55:50PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:
>> On Thu, Aug 02, 2007 at 09:19:06AM +0300, john@screen.lv (john@screen.lv) wrote:
>> > 1186035057.207629 127.0.0.1 -> 127.0.0.1 TCP 50000 > smtp [SYN]
>> > Seq=0 Len=0
>> > 1186035057.207632 127.0.0.1 -> 127.0.0.1 TCP smtp > 50000 [SYN, ACK]
>> > Seq=0 Ack=1 Win=32792 Len=0 MSS=16396
>> > 1186035057.207666 127.0.0.1 -> 127.0.0.1 TCP 50000 > smtp [ACK]
>> > Seq=1 Ack=1 Win=1500 Len=0
>> > 1186035057.207699 127.0.0.1 -> 127.0.0.1 SMTP Command: EHLO localhost
>> > 1186035057.207718 127.0.0.1 -> 127.0.0.1 TCP smtp > 50000 [ACK]
>> > Seq=1 Ack=17 Win=32792 Len=0
>> > 1186035057.207736 127.0.0.1 -> 127.0.0.1 TCP 50000 > smtp [RST]
>> > Seq=17 Len=0
>> > 1186035057.223934 127.0.0.1 -> 127.0.0.1 TCP 33787 > 50000 [RST,
>> > ACK] Seq=0 Ack=0 Win=32792 Len=0
>> >
>> > Can someone please comment as to why, tcp stack sends rst packet from the
>> > wrong source port in this situation.
>>
>> Besides the fact, that test applications do not run if started not as
>> root, I got this:
>
> And it actually does not initializes a session, since tird line below
> shows RST, but not ack. The same with sendmail smtp server (i.e. 25 port
> like in your server) and unmodified client.
> Please provide application which can trigger the issue and I will help
> to debug this issue. If it will help you to debug client, I can run
> tcpdump on public server (say 194.85.82.65, please tell me your source
> address) to collect dumps. Current code does not trigger the issue on my
> machines (and works not like was intended by you). Ugh, and code really
> looks horrible...
>
I just got multiple RSTs instead of a connection too. The second RST looks
like it's from another connection - and a RST for a RST is wrong...
--
Simon Arlott
^ permalink raw reply
* Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
From: Satyam Sharma @ 2007-08-02 11:40 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Matt Mackall, Jarek Poplawski, Gabriel C, Andrew Morton,
Linux Kernel Mailing List, netdev, jason.wessel, amitkale, zippel,
jengelh
In-Reply-To: <alpine.LFD.0.999.0708021547420.8258@enigma.security.iitk.ac.in>
[ Read through the thread, looked at Kconfig files,
did some tests. Adding Kconfig experts to Cc: list. ]
> On Thu, 2 Aug 2007, Sam Ravnborg wrote:
>
> > > >
> > > > ...
> > > > endif # NETDEVICES
> > > >
> > > > config NETPOLL
> > > > depends on NETDEVICES
> > > > def_bool NETCONSOLE
> > > >
> > > > config NETPOLL_TRAP
> > > > bool "Netpoll traffic trapping"
> > > > default n
> > > > depends on NETPOLL
> > > >
> > > > config NET_POLL_CONTROLLER
> > > > def_bool NETPOLL
> > > > depends on NETPOLL
Gargh, what we're seeing here is a whole bunch of bugs, I think. First
I thought this must be one of those randconfig-producing-wrong-configs
issues, but surprisingly, running "make oldconfig" on this .config on
a fresh 2.6.23-rc1-mm1 tree didn't change anything in the .config.
Kconfig bug #1:
===============
Which means, although:
*****
menuconfig BAZ
if BAZ
config BAR
endif
*****
is widely believed (by most folks, I've heard this on several threads,
and as written in the comment in drivers/net/Kconfig) to be equivalent to:
*****
menuconfig BAZ
if BAZ
endif
config BAR
depends on BAZ
*****
this is *not* enforced by "make oldconfig"! And hence, the NETPOLL &&
!NETDEVICES situation we're seeing here.
[ We could also categorize this as a bug in Kconfig's "if", fwiw. ]
Kconfig bug #2:
===============
config FOO
def_bool BAR
is supposed to ensure that FOO == BAR (as Matt mentioned earlier).
However, even this is *not* enforced by "make oldconfig". And hence,
the NETPOLL && !NET_POLL_CONTROLLER situation we're seeing here.
In fact, I believe it's possible to even pass a NETCONSOLE but
!NETPOLL kind of .config through "make oldconfig" but it still won't
catch it, and build breakages *will* occur.
[ We could also categorize this as a bug in Kconfig's "def_bool", fwiw. ]
Possibly, we could also decide to just blame "randconfig" for the whole
issue, and forget about these, because I think it's highly unlikely
(though not impossible) for people with "real" .configs to hit the
problems we saw above.
KGDBOE bug #1:
==============
config KGDBOE in lib/Kconfig.kgdb must also "depend on" NETDEVICES,
and select NET_POLL_CONTROLLER also.
KGDBOE bug #2:
==============
config KGDBOE_NOMODULE is a sad, sad option, and must be killed. The
"if !KGDBOE_NOMODULE" in KGDBOE must be removed, and it must lose its
dependency on "m".
Satyam
^ permalink raw reply
* Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
From: Satyam Sharma @ 2007-08-02 11:56 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Sam Ravnborg, Matt Mackall, Gabriel C, Andrew Morton,
linux-kernel, netdev, jason.wessel, amitkale
In-Reply-To: <20070802114042.GB1699@ff.dom.local>
On Thu, 2 Aug 2007, Jarek Poplawski wrote:
> On Thu, Aug 02, 2007 at 04:02:21PM +0530, Satyam Sharma wrote:
> [...]
> How often "common" developer has to make such decisions in Kconfig?
> Probably no more than once per year. So, it's fair to blame anybody
> for not reading lkml to find if there are some bugs or
> recommendations before using apparently simple tool? I think there
> is usually some README for such things (maybe in Documentation/)?
Whoops, I only said that in humour, probably should've snuck in a
smiley or two. Definitely not blaming anybody. Apologies to anyone
who felt offended, sorry, nothing such was intended, I assure.
Satyam
^ permalink raw reply
* Re: strange tcp behavior
From: Evgeniy Polyakov @ 2007-08-02 12:04 UTC (permalink / raw)
To: Simon Arlott; +Cc: john, netdev
In-Reply-To: <36758.simon.1186054739@5ec7c279.invalid>
On Thu, Aug 02, 2007 at 12:38:59PM +0100, Simon Arlott (simon@fire.lp0.eu) wrote:
> I just got multiple RSTs instead of a connection too. The second RST looks
> like it's from another connection - and a RST for a RST is wrong...
You should use iptables rule to block non-raw access:
iptables -I INPUT -p tcp --dport 50000 -j DROP
but even in that case I got valid session.
> --
> Simon Arlott
--
Evgeniy Polyakov
^ permalink raw reply
* Re: strange tcp behavior
From: Simon Arlott @ 2007-08-02 12:15 UTC (permalink / raw)
To: john; +Cc: johnpol, netdev
In-Reply-To: <46860.212.93.96.73.1186055105.squirrel@mail.screen.lv>
(Don't remove CC:s, don't top post)
>> On Thu, August 2, 2007 11:16, Evgeniy Polyakov wrote:
>>> On Thu, Aug 02, 2007 at 01:55:50PM +0400, Evgeniy Polyakov
>>> (johnpol@2ka.mipt.ru) wrote:
>>>> On Thu, Aug 02, 2007 at 09:19:06AM +0300, john@screen.lv
>>>> (john@screen.lv) wrote:
>>>> > 1186035057.207629 127.0.0.1 -> 127.0.0.1 TCP 50000 > smtp [SYN]
>>>> > Seq=0 Len=0
>>>> > 1186035057.207632 127.0.0.1 -> 127.0.0.1 TCP smtp > 50000 [SYN,
>>>> ACK]
>>>> > Seq=0 Ack=1 Win=32792 Len=0 MSS=16396
>>>> > 1186035057.207666 127.0.0.1 -> 127.0.0.1 TCP 50000 > smtp [ACK]
>>>> > Seq=1 Ack=1 Win=1500 Len=0
>>>> > 1186035057.207699 127.0.0.1 -> 127.0.0.1 SMTP Command: EHLO
>>>> localhost
>>>> > 1186035057.207718 127.0.0.1 -> 127.0.0.1 TCP smtp > 50000 [ACK]
>>>> > Seq=1 Ack=17 Win=32792 Len=0
>>>> > 1186035057.207736 127.0.0.1 -> 127.0.0.1 TCP 50000 > smtp [RST]
>>>> > Seq=17 Len=0
>>>> > 1186035057.223934 127.0.0.1 -> 127.0.0.1 TCP 33787 > 50000
>>>> [RST,
>>>> > ACK] Seq=0 Ack=0 Win=32792 Len=0
>>>> >
>>>> > Can someone please comment as to why, tcp stack sends rst packet
>>>> from the
>>>> > wrong source port in this situation.
>>>>
>>>> Besides the fact, that test applications do not run if started not as
>>>> root, I got this:
>>>
>>> And it actually does not initializes a session, since tird line below
>>> shows RST, but not ack. The same with sendmail smtp server (i.e. 25 port
>>> like in your server) and unmodified client.
>>> Please provide application which can trigger the issue and I will help
>>> to debug this issue. If it will help you to debug client, I can run
>>> tcpdump on public server (say 194.85.82.65, please tell me your source
>>> address) to collect dumps. Current code does not trigger the issue on my
>>> machines (and works not like was intended by you). Ugh, and code really
>>> looks horrible...
>>>
>>
>> I just got multiple RSTs instead of a connection too. The second RST looks
>> like it's from another connection - and a RST for a RST is wrong...
On Thu, August 2, 2007 12:45, john@screen.lv wrote:
> you need to add iptables rule for this to
> work, or else the tcp resets connection too early because it does not know
> that something is listening on 50000 port.
>
> iptables -I INPUT -p tcp --dport 50000 -j DROP should do the job.
You didn't mention this before.
Without the server running:
13:02:23.314352 IP 127.0.0.1.50000 > 127.0.0.1.2500: S 53123695:53123695(0) win 1500
13:02:23.314442 IP 127.0.0.1.2500 > 127.0.0.1.50000: R 0:0(0) ack 53123696 win 0
13:02:25.906975 IP 127.0.0.1.3315 > 127.0.0.1.49197: P 1285306902:1285307318(416) ack 1267361915 win 1024
<nop,nop,timestamp 3575709021 3575672670>
13:02:25.907060 IP 127.0.0.1.49197 > 127.0.0.1.3315: . ack 416 win 1541 <nop,nop,timestamp 3575709021
3575709021>
With the server running:
13:05:55.234696 IP 127.0.0.1.50000 > 127.0.0.1.2500: S 1960601450:1960601450(0) win 1500
13:05:55.234799 IP 127.0.0.1.2500 > 127.0.0.1.50000: S 2171862150:2171862150(0) ack 1960601451 win 32792
<mss 16396>
13:05:55.238271 IP 127.0.0.1.50000 > 127.0.0.1.2500: . ack 1 win 1500
13:05:55.240034 IP 127.0.0.1.50000 > 127.0.0.1.2500: P 1:17(16) ack 1 win 1500
13:05:55.240132 IP 127.0.0.1.2500 > 127.0.0.1.50000: . ack 17 win 32792
13:05:55.242251 IP 127.0.0.1.50000 > 127.0.0.1.2500: R 1960601467:1960601467(0) win 1500
13:05:55.253884 IP 127.0.0.1.56434 > 127.0.0.1.50000: R 2171862151:2171862151(0) ack 1960601467 win 32792
Weird. I resent your final RST a few times with a delay:
13:13:05.199275 IP 127.0.0.1.50000 > 127.0.0.1.2500: S 83018811:83018811(0) win 1500
13:13:05.199378 IP 127.0.0.1.2500 > 127.0.0.1.50000: S 2627922927:2627922927(0) ack 83018812 win 32792 <mss
16396>
13:13:05.203368 IP 127.0.0.1.50000 > 127.0.0.1.2500: . ack 1 win 1500
13:13:05.205049 IP 127.0.0.1.50000 > 127.0.0.1.2500: P 1:17(16) ack 1 win 1500
13:13:05.205173 IP 127.0.0.1.2500 > 127.0.0.1.50000: . ack 17 win 32792
13:13:05.206463 IP 127.0.0.1.50000 > 127.0.0.1.2500: R 83018828:83018828(0) win 1500
13:13:05.207656 IP 127.0.0.1.50000 > 127.0.0.1.2500: R 83018828:83018828(0) win 1500
13:13:05.217664 IP 127.0.0.1.55271 > 127.0.0.1.50000: R 2627922928:2627922928(0) ack 83018828 win 32792
13:13:05.510239 IP 127.0.0.1.50000 > 127.0.0.1.2500: R 83018828:83018828(0) win 1500
13:13:05.511644 IP 127.0.0.1.50000 > 127.0.0.1.2500: R 83018828:83018828(0) win 1500
13:13:05.512764 IP 127.0.0.1.50000 > 127.0.0.1.2500: R 83018828:83018828(0) win 1500
I don't know where that extra RST is coming from.
This test would be more convincing between two hosts, since your bizarre
client is using raw sockets as root and could be doing anything.
--
Simon Arlott
^ permalink raw reply
* Re: strange tcp behavior
From: Evgeniy Polyakov @ 2007-08-02 12:28 UTC (permalink / raw)
To: Simon Arlott; +Cc: john, netdev
In-Reply-To: <20070802120452.GB9975@2ka.mipt.ru>
On Thu, Aug 02, 2007 at 04:04:53PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:
> On Thu, Aug 02, 2007 at 12:38:59PM +0100, Simon Arlott (simon@fire.lp0.eu) wrote:
> > I just got multiple RSTs instead of a connection too. The second RST looks
> > like it's from another connection - and a RST for a RST is wrong...
>
> You should use iptables rule to block non-raw access:
> iptables -I INPUT -p tcp --dport 50000 -j DROP
>
> but even in that case I got valid session.
Ok, I can now reproduce the problem.
I will try to debug it further.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
From: Jarek Poplawski @ 2007-08-02 12:52 UTC (permalink / raw)
To: Satyam Sharma
Cc: Sam Ravnborg, Matt Mackall, Gabriel C, Andrew Morton,
linux-kernel, netdev, jason.wessel, amitkale
In-Reply-To: <alpine.LFD.0.999.0708021721230.8258@enigma.security.iitk.ac.in>
On Thu, Aug 02, 2007 at 05:26:12PM +0530, Satyam Sharma wrote:
...
> Whoops, I only said that in humour, probably should've snuck in a
> smiley or two. Definitely not blaming anybody. Apologies to anyone
> who felt offended, sorry, nothing such was intended, I assure.
I see you probably didn't notice my smileys too. I need them so often
that I've to abbreviate them with something like this: ",.?!"
But, I'm also sorry if you felt confused I felt offended etc...
Jarek P.
^ permalink raw reply
* Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
From: Geert Uytterhoeven @ 2007-08-02 13:58 UTC (permalink / raw)
To: Michael Buesch
Cc: Andrew Morton, linux-kernel, bcm43xx-dev, netdev, linux-wireless,
Gary Zambrano
In-Reply-To: <200707271857.24162.mb@bu3sch.de>
On Fri, 27 Jul 2007, Michael Buesch wrote:
> The Sonics Silicon Backplane is a mini-bus used on
> various Broadcom chips and embedded devices.
> Devices using the SSB include b44, bcm43xx and various
> Broadcom based wireless routers.
> A b44 and bcm43xx port and a SSB based OHCI driver is available.
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -58,6 +58,8 @@ source "drivers/power/Kconfig"
>
> source "drivers/hwmon/Kconfig"
>
> +source "drivers/ssb/Kconfig"
> +
> source "drivers/mfd/Kconfig"
>
> source "drivers/media/Kconfig"
> --- /dev/null
> +++ b/drivers/ssb/Kconfig
> @@ -0,0 +1,92 @@
> +menu "Sonics Silicon Backplane"
> +
> +config SSB
> + tristate "Sonics Silicon Backplane support"
> + depends on EXPERIMENTAL
Hence this will show up on all platforms?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
From: Michael Buesch @ 2007-08-02 14:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Andrew Morton, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, linux-kernel,
Gary Zambrano, bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w
In-Reply-To: <Pine.LNX.4.64.0708021557280.5150@anakin>
On Thursday 02 August 2007, Geert Uytterhoeven wrote:
> On Fri, 27 Jul 2007, Michael Buesch wrote:
> > The Sonics Silicon Backplane is a mini-bus used on
> > various Broadcom chips and embedded devices.
> > Devices using the SSB include b44, bcm43xx and various
> > Broadcom based wireless routers.
> > A b44 and bcm43xx port and a SSB based OHCI driver is available.
>
> > --- a/drivers/Kconfig
> > +++ b/drivers/Kconfig
> > @@ -58,6 +58,8 @@ source "drivers/power/Kconfig"
> >
> > source "drivers/hwmon/Kconfig"
> >
> > +source "drivers/ssb/Kconfig"
> > +
> > source "drivers/mfd/Kconfig"
> >
> > source "drivers/media/Kconfig"
>
> > --- /dev/null
> > +++ b/drivers/ssb/Kconfig
> > @@ -0,0 +1,92 @@
> > +menu "Sonics Silicon Backplane"
> > +
> > +config SSB
> > + tristate "Sonics Silicon Backplane support"
> > + depends on EXPERIMENTAL
>
> Hence this will show up on all platforms?
So?
^ permalink raw reply
* Re: [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
From: Vlad Yasevich @ 2007-08-02 14:40 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev, Neil Horman, lksctp-developers, Sridhar Samudrala
In-Reply-To: <46B19C88.8070104@cn.fujitsu.com>
Wei Yongjun wrote:
> Patch has been modified base on comment.
> Thanks.
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>
Ok, I've applied this patch, but in the future, please
generate patches so that they can be applied
with a -p1 flag.
Please see Documentation/SubmittingPatches for proper
format.
Thanks
-vlad
^ permalink raw reply
* Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
From: Matt Mackall @ 2007-08-02 15:59 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Gabriel C, Andrew Morton, linux-kernel, netdev, jason.wessel,
amitkale, Sam Ravnborg
In-Reply-To: <20070802090008.GA1699@ff.dom.local>
On Thu, Aug 02, 2007 at 11:00:08AM +0200, Jarek Poplawski wrote:
> On Wed, Aug 01, 2007 at 09:02:19PM -0500, Matt Mackall wrote:
> > On Wed, Aug 01, 2007 at 11:59:21AM +0200, Jarek Poplawski wrote:
> > > On Tue, Jul 31, 2007 at 05:05:00PM +0200, Gabriel C wrote:
> > > > Jarek Poplawski wrote:
> > > > > On Tue, Jul 31, 2007 at 12:14:36PM +0200, Gabriel C wrote:
> > > > >> Jarek Poplawski wrote:
> > > > >>> On 28-07-2007 20:42, Gabriel C wrote:
> > > > >>>> Andrew Morton wrote:
> > > > >>>>> On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <nix.or.die@googlemail.com> wrote:
> ...
> > > > >>>>>> net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller'
> ...
> > > > >>>>>> I think is because KGDBOE selects just NETPOLL.
> > > > >>>>>>
> > > > >>>>> Looks like it.
> > > > >>>>>
> > > > >>>>> Select went and selected NETPOLL and NETPOLL_TRAP but things like
> > > > >>>>> CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select'
> > > > >>>>> remains evil.
> ...
> > > seems to select NET_POLL_CONTROLLER after selecting NETPOLL, but
> > > still doesn't check for NETDEVICES dependency.
> >
> > That's odd. Adding Sam to the cc:.
>
> Looks right, but after reading Andrew's opinion about select I'd be
> astonished if he doesn't know this problem already.
>
> >
> > > > >> Now KGDBOE just selects NETPOLL and NETPOLL_TRAP.
> > > > >> Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but the question is does it work without any ethernet card ?
> > > > >
> > > > > Why kgdboe should care what netpoll needs? So, I hope, you are adding
> > > > > this select under config NETPOLL. On the other hand, if NETPOLL should
> > > > > depend on NET_POLL_CONTROLLER there is probably no reason to have them
> > > > > both.
> > > >
> > > > NET_POLL_CONTROLLER has def_bool NETPOLL if NETDEVICES .
> > > >
> > > > Net peoples ping ?:)
> >
> > How about cc:ing the netpoll maintainer?
>
> Is there a new one or do you suggest possibility of abusing the
> authority of the netpoll's author with such trifles...?!
I'm just subtly suggesting that if you're going to have a discussion
about netpoll, you ought to cc: me.
> There are some notions about "other diagnostic tools" in some
> net drivers, eg. 3c509.c, so there would be a little bit of
> work if, after changing this, they really exist (and even if
> not - maybe it's reasonable to save such possibility for the
> future?).
I created it for netpoll, only netpoll clients have ever cared.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
From: Geert Uytterhoeven @ 2007-08-02 16:12 UTC (permalink / raw)
To: Michael Buesch
Cc: Andrew Morton, linux-kernel, bcm43xx-dev, netdev, linux-wireless,
Gary Zambrano
In-Reply-To: <200708021624.59701.mb@bu3sch.de>
On Thu, 2 Aug 2007, Michael Buesch wrote:
> On Thursday 02 August 2007, Geert Uytterhoeven wrote:
> > On Fri, 27 Jul 2007, Michael Buesch wrote:
> > > The Sonics Silicon Backplane is a mini-bus used on
> > > various Broadcom chips and embedded devices.
> > > Devices using the SSB include b44, bcm43xx and various
> > > Broadcom based wireless routers.
> > > A b44 and bcm43xx port and a SSB based OHCI driver is available.
> >
> > > --- a/drivers/Kconfig
> > > +++ b/drivers/Kconfig
> > > @@ -58,6 +58,8 @@ source "drivers/power/Kconfig"
> > >
> > > source "drivers/hwmon/Kconfig"
> > >
> > > +source "drivers/ssb/Kconfig"
> > > +
> > > source "drivers/mfd/Kconfig"
> > >
> > > source "drivers/media/Kconfig"
> >
> > > --- /dev/null
> > > +++ b/drivers/ssb/Kconfig
> > > @@ -0,0 +1,92 @@
> > > +menu "Sonics Silicon Backplane"
> > > +
> > > +config SSB
> > > + tristate "Sonics Silicon Backplane support"
> > > + depends on EXPERIMENTAL
> >
> > Hence this will show up on all platforms?
>
> So?
Shouldn't you add a dependency for platforms where it make sense to have SSB?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
From: Michael Buesch @ 2007-08-02 16:18 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Andrew Morton, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, linux-kernel,
Gary Zambrano, bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w
In-Reply-To: <Pine.LNX.4.64.0708021812260.5150@anakin>
On Thursday 02 August 2007, Geert Uytterhoeven wrote:
> On Thu, 2 Aug 2007, Michael Buesch wrote:
> > On Thursday 02 August 2007, Geert Uytterhoeven wrote:
> > > On Fri, 27 Jul 2007, Michael Buesch wrote:
> > > > The Sonics Silicon Backplane is a mini-bus used on
> > > > various Broadcom chips and embedded devices.
> > > > Devices using the SSB include b44, bcm43xx and various
> > > > Broadcom based wireless routers.
> > > > A b44 and bcm43xx port and a SSB based OHCI driver is available.
> > >
> > > > --- a/drivers/Kconfig
> > > > +++ b/drivers/Kconfig
> > > > @@ -58,6 +58,8 @@ source "drivers/power/Kconfig"
> > > >
> > > > source "drivers/hwmon/Kconfig"
> > > >
> > > > +source "drivers/ssb/Kconfig"
> > > > +
> > > > source "drivers/mfd/Kconfig"
> > > >
> > > > source "drivers/media/Kconfig"
> > >
> > > > --- /dev/null
> > > > +++ b/drivers/ssb/Kconfig
> > > > @@ -0,0 +1,92 @@
> > > > +menu "Sonics Silicon Backplane"
> > > > +
> > > > +config SSB
> > > > + tristate "Sonics Silicon Backplane support"
> > > > + depends on EXPERIMENTAL
> > >
> > > Hence this will show up on all platforms?
> >
> > So?
>
> Shouldn't you add a dependency for platforms where it make sense to have SSB?
Well, that's everything where you can stick a PCI, PCMCIA, PC-Card or CF-Card
into, plus the MIPS platform, where we have the embedded SSB.
That's basically everything, no? Except these strange !HAS_IOMEM platforms,
which we already take care of in a followup patch.
^ permalink raw reply
* b44 compile error on !PCI
From: Meelis Roos @ 2007-08-02 16:45 UTC (permalink / raw)
To: netdev
Tryng to compile todays git on SBus-only Sparc64 (Ultra 1), no PCI. b44
is selectable but fails to compile:
CC [M] drivers/net/b44.o
drivers/net/b44.c: In function 'b44_sync_dma_desc_for_device':
drivers/net/b44.c:134: error: implicit declaration of function 'dma_sync_single_range_for_device'
drivers/net/b44.c: In function 'b44_sync_dma_desc_for_cpu':
drivers/net/b44.c:144: error: implicit declaration of function 'dma_sync_single_range_for_cpu'
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: TCP SACK issue, hung connection, tcpdump included
From: Darryl Miles @ 2007-08-02 16:58 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: LKML, Netdev
In-Reply-To: <Pine.LNX.4.64.0708021056560.8788@kivilampi-30.cs.helsinki.fi>
Ilpo Järvinen wrote:
> On Tue, 31 Jul 2007, Darryl L. Miles wrote:
>
>> I've been able to capture a tcpdump from both ends during the problem and its
>> my belief there is a bug in 2.6.20.1 (at the client side) in that it issues a
>> SACK option for an old sequence which the current window being advertised is
>> beyond it. This is the most concerning issue as the integrity of the sequence
>> numbers doesn't seem right (to my limited understanding anyhow).
>
> You probably didn't check the reference I explicitly gave to those who
> are not familiar how DSACK works, just in case you didn't pick it up last
> time, here it is again for you: RFC2883...
I've now squinted the D-SACK RFC and understand a little about this,
however the RFC does make the claim "This extension is compatible with
current implementations of the SACK option in TCP. That is, if one of
the TCP end-nodes does not implement this D-SACK extension and the other
TCP end-node does, we believe that this use of the D-SACK extension by
one of the end nodes will not introduce problems."
What if it turns out that is not true for a large enough number of SACK
implementations out there; in the timeframe that SACK was supported but
D-SACK was not supported. Would it be possible to clearly catagorise an
implementation to be:
* 100% SACK RFC compliant. SACK works and by virtue of the mandatory
requirements written into the previous SACK RFCs then this
implementation would never see a problem with receiving D-SACK even
through the stack itself does not support D-SACK.
* Mostly SACK RFC compliant. SACK works but if it saw D-SACK it would
have a problems dealing with it, possibly resulting in fatal TCP
lockups. Are there SACK implementation mandatory requirements in place
for to be able to clearly draw the line and state that the 2.6.9 SACK
implementation was not RFC compliant.
* 100% SACK and D-DACK RFC compliant. Such an implementation was
written to support D-SACK on top of SACK.
So if there is a problem whos fault would it be:
* The original SACK RFCs for not specifying a mandatory course of
action to take which D-SACK exploits. Thus making the claim in RFC2883
unsound.
* The older linux kernel for not being 100% SACK RFC compliant in its
implementation ? Not a lot we can do about this now, but if we're able
to identify there maybe backward compatibility issues with the same
implementation thats a useful point to take forward.
* The newer linux kernel for enabling D-SACK by default when RFC2883
doesn't even claim a cast iron case for D-SACK to be compatible with any
100% RFC compliant SACK implementation.
Does TCP support the concept of vendor dependent options, that would be
TCP options which are in a special range that would both identify the
vendor and the vendors-specific option id. Such a system would allow
Linux to implement a <D-SACK Ok> option, even if the RFC claims one is
not needed. This would allow moving forward through this era until such
point in time when it was officially agreed it was just a linux problem
or an RFC problem. If its an RFC problem then IANA (or whoever) would
issue a generic TCP option for it.
If the dump on this problem really does identify a risk/problem when as
its between 2 version of linux a vendor specific option also makes sense.
I don't really want to switch new useful stuff off by default (so it
never gets used), I'm all for experimentation but not to the point of
failure between default configurations of widely distributed version of
the kernel.
So thats the technical approaches I can come up with to discuss. Does
Ilpo have a particular vested interest in D-SACK that should be disclosed?
> However, if DSACKs really
> bother you still (though it shouldn't :-)), IIRC I also told you how
> you're able to turn it off (tcp_dsack sysctl) but I assure you that it's
> not a bug but feature called DSACK [RFC2883], there's _absolutely_
nothing
> wrong with it, instead, it would be wrong to _not_ send the below
snd_una
> SACK in this scenario when tcp_dsack set to 1.
So it is necessary to turn off a TCP option (that is enabled by default)
to be sure to have reliable TCP connections (that don't lock up) in the
bugfree Linux networking stack ? This is absurd.
If such an option causes such a problem; then that option should not be
enabled by default. If however the problem is because of a bug then let
us continue to try to isolate the cause rather than wallpaper over the
cracks with the voodoo of turning things that are enabled by default off.
It only makes sense to turn options off when there is a 3rd party
involved (or other means beyond your control) which is affecting
function, the case here is that two Linux kernel stacks are affected and
no 3rd party device has been shown to be affecting function.
>> There is another concern of why the SERVER performed a retransmission in the
>> first place, when the tcpdump shows the ack covering it has been seen.
>
> There are only three possible reasons to this thing:
> 1) The ACK didn't reach the SERVER (your logs prove this to not be the
> case)
> 2) The ACK got discarded by the SERVER
I'd thought about that one, its a possibility. The server in question
does have period of high UDP load on a fair number of UDP sockets at
once (a few 1000). Both systems have 2Gb of RAM. The server has maybe
just 250Mb of RSS of all apps combined.
> 3) The SERVER (not the client) is buggy and sends an incorrect
> retransmission
This was my initial stab at the cause, simply due to the sequence like
this (from when the lockup starts) :
03:58:56.731637 IP (tos 0x10, ttl 64, id 53311, offset 0, flags [DF],
proto 6, length: 64) CLIENT.43726 > SERVER.ssh: . [tcp sum ok]
2634113543:2634113543(0) ack 617735600 win 501 <nop,nop,timestamp
819458962 16345815,nop,nop,sack sack 1 {617733440:617734888} >
03:58:57.322800 IP (tos 0x0, ttl 50, id 28689, offset 0, flags [DF],
proto 6, length: 1500) SERVER.ssh > CLIENT.43726: .
617733440:617734888(1448) ack 2634113543 win 2728 <nop,nop,timestamp
16346718 819458864>
The client sent a SACK. But from understanding more about D-SACK, this
is a valid D-SACK response, but it appears to confuse the older Linux
kernel at the server end.
> ...So we have just two options remaining...
>
>> I have made available the full dumps at:
>>
>> http://darrylmiles.org/snippets/lkml/20070731/
>
> Thanks about these... Based on a quick check, it is rather clear that the
> SERVER is for some reason discarding the packets it's receiving:
>
> 04:11:26.833935 IP CLIENT.43726 > SERVER.ssh: P 4239:4287(48) ack 28176 win 501 <nop,nop,timestamp 819646456 16345815>
> 04:11:27.132425 IP SERVER.ssh > CLIENT.43726: . 26016:27464(1448) ack 4239 win 2728 <nop,nop,timestamp 17096579 819458864>
> 04:11:27.230081 IP CLIENT.43726 > SERVER.ssh: . ack 28176 win 501 <nop,nop,timestamp 819646555 16345815,nop,nop
>
> Notice, (cumulative) ack field didn't advance though new data arrived, and
> for the record, it's in advertised window too. There are no DSACK in here
> so your theory about below snd_una SACK won't help to explain this one
> at all... We'll just have to figure out why it's discarding it. And
> there's even more to prove this...
Agreed on this. However discarding data is allowed (providing it is
intentional discarding not a bug where the TCP stack is discarding
segments it shouldn't), TCP should recover providing sufficient packets
get through.
So the SNMP data would show up intentional discards (due to
memory/resource issues). So I'll get some of those too.
>> ...SNIPPED...MORE SIGNS OF UNEXPLAINED DISCARDING BY THE SERVER...
>
> There was one bad checksum btw:
>
>> 03:58:56.365662 IP (tos 0x10, ttl 64, id 28685, offset 0, flags [DF],
>> proto 6, length: 764) SERVER.ssh > CLIENT.43726: P [bad tcp cksum 6662
>> (->ef2b)!] 617734888:617735600(712) ack 2634113543 win 2728
>> <nop,nop,timestamp 16345815 819458859>
I noticed this one too, but discarded the "[bad tcp cksum 6662
->ef2b)!]" as bogus on the basis of the following packet turning up at
the client:
03:58:56.422019 IP (tos 0x0, ttl 50, id 28685, offset 0, flags [DF],
proto 6, length: 764) SERVER.ssh > CLIENT.43726: P [tcp sum ok]
617734888:617735600(712) ack 2634113543 win 2728 <nop,nop,timestamp
16345815 819458859>
Forgive me if I am mistaken, but while the server reports a checksum
error, the client did not. I took this to be a misreporting by tcpdump
at the server, probably due to the "e1000" network card checksum
offloading (I'd guess this level of card does offloading, I've never
audited the driver before). If you search both dumps for the timestamps
"16345815 819458859" two packets were sent by the server and two
received by the server with those timestamps.
>> There are some changes in 2.6.22 that appear to affect TCP SACK handling
>> does this fix a known issue ?
>
> There is no such "known issue" :-)... This issue has nothing to do with
> TCP SACK handling, since that code _won't_ be reached... We could verify
> that from the timestamps. But if you still insist that SACK under snd_una
> is the issue, please turn tcp_dsack to 0 on the CLIENT, you will not get
> them after that and you can be happy as your out-of-window SACK "issue"
> is then fixed :-)...
I had thrown up one interpretation of events for others to comment, so
thanks for your comments and viewpoint on the issue.
> ...Seriously, somebody else than me is probably better in suggesting what
> could cause the discarding at the SERVER in this case. SNMP stuff Dave was
> asking could help, you can find them from /proc/net/{netstat,snmp}...
The SNMP stats aren't so useful right now as
the box has been rebooted since then but I shall attempt to capture
/proc/net/* data, cause the problem, then capture /proc/net/* data again
if those numbers can help.
Darryl
^ permalink raw reply
* Re: [patch] genirq: temporary fix for level-triggered IRQ resend
From: Gabriel C @ 2007-08-02 17:03 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Jarek Poplawski, Thomas Gleixner,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton, Alan Cox, marcin.slusarz
In-Reply-To: <20070731155843.GA7033@elte.hu>
Ingo Molnar wrote:
> Linus,
>
> with -rc2 approaching i think we should apply the minimal fix below to
> get Marcin's ne2k-pci networking back in working order. The
> WARN_ON_ONCE() will not prevent the system from working and it will be a
> reminder.
>
> a better workaround would be to inhibit the resent vector via the
> IO-APIC irqchip - but i'd still like to have the patch below because the
> ne2k driver _should_ be able to survive the spurious irq that happens.
> (even on Marcin's system that ne2k-pci irq line is shared with another
> networking card, so an irq could happen at any moment - it's just that
> with the delayed-disable logic it happens _all the time_.)
>
I get a warning on each boot now with this patch ..
[ 63.686613] WARNING: at kernel/irq/resend.c:70 check_irq_resend()
[ 63.686636] [<c013c55c>] check_irq_resend+0x8c/0xa0
[ 63.686653] [<c013c15f>] enable_irq+0xad/0xb3
[ 63.686662] [<e886481e>] vortex_timer+0x20c/0x3d5 [3c59x]
[ 63.686675] [<c01164b9>] scheduler_tick+0x154/0x273
[ 63.686685] [<c012fed1>] getnstimeofday+0x34/0xe3
[ 63.686697] [<c0121f4a>] run_timer_softirq+0x137/0x197
[ 63.686709] [<e8864612>] vortex_timer+0x0/0x3d5 [3c59x]
[ 63.686720] [<c011ed09>] __do_softirq+0x75/0xe1
[ 63.686729] [<c011edac>] do_softirq+0x37/0x3d
[ 63.686735] [<c011ef85>] irq_exit+0x7c/0x7e
[ 63.686740] [<c010e013>] smp_apic_timer_interrupt+0x59/0x84
[ 63.686751] [<c0103428>] apic_timer_interrupt+0x28/0x30
[ 63.686759] [<c0101355>] default_idle+0x0/0x3f
[ 63.686767] [<c0101385>] default_idle+0x30/0x3f
[ 63.686773] [<c0100c19>] cpu_idle+0x5e/0x8e
[ 63.686779] [<c03fdc5f>] start_kernel+0x2d7/0x368
That means ?:)
> Ingo
>
Gabriel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox