All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: [PATCH] Simplify yenta code
@ 2007-10-06  4:26 Komuro
  2007-10-08 17:47 ` Linas Vepstas
  2007-10-13 22:36 ` [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC Komuro
  0 siblings, 2 replies; 23+ messages in thread
From: Komuro @ 2007-10-06  4:26 UTC (permalink / raw)
  To: linux-kernel; +Cc: linas

Hello,

Unfortunately, your patch is wrong,
and does not results in the same run-time behaviour.

You broke the code of "if (type & IORESOURCE_IO)"
 

Best Regards
Komuro


>Simplify some of the resource detection logic in yenta_socket.
>This patch results in the same run-time behaviour as the 
>current code, but does so with fewer lines of code. This
>makes the logical flow of the code a bit easier to understand.
>
>Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>Cc: Dominik Brodowski <linux@brodo.de>
>
>----
> drivers/pcmcia/yenta_socket.c |   22 ++++++++--------------
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
>Index: linux-2.6.23-rc8-mm1/drivers/pcmcia/yenta_socket.c
>===================================================================
>--- linux-2.6.23-rc8-mm1.orig/drivers/pcmcia/yenta_socket.c	2007-10-01 >12:17:02.000000000 -0500
>+++ linux-2.6.23-rc8-mm1/drivers/pcmcia/yenta_socket.c	2007-10-01 12:37:36.000000000 >-0500
>@@ -654,20 +654,14 @@ static int yenta_allocate_res(struct yen
> 				pci_name(socket->dev), nr);
> 	}
> 
>-	if (type & IORESOURCE_IO) {
>-		if ((yenta_search_res(socket, res, BRIDGE_IO_MAX)) ||
>-		    (yenta_search_res(socket, res, BRIDGE_IO_ACC)) ||
>-		    (yenta_search_res(socket, res, BRIDGE_IO_MIN)))
>-			return 1;
>-	} else {
>-		if (type & IORESOURCE_PREFETCH) {
>-			if ((yenta_search_res(socket, res, BRIDGE_MEM_MAX)) ||
>-			    (yenta_search_res(socket, res, BRIDGE_MEM_ACC)) ||
>-			    (yenta_search_res(socket, res, BRIDGE_MEM_MIN)))
>-				return 1;
>-			/* Approximating prefetchable by non-prefetchable */
>-			res->flags = IORESOURCE_MEM;
>-		}
>+	if ((yenta_search_res(socket, res, BRIDGE_MEM_MAX)) ||
>+	    (yenta_search_res(socket, res, BRIDGE_MEM_ACC)) ||
>+	    (yenta_search_res(socket, res, BRIDGE_MEM_MIN)))
>+		return 1;
>+
>+	if (type & IORESOURCE_PREFETCH) {
>+		/* Approximating prefetchable by non-prefetchable */
>+		res->flags = IORESOURCE_MEM;
> 		if ((yenta_search_res(socket, res, BRIDGE_MEM_MAX)) ||
> 		    (yenta_search_res(socket, res, BRIDGE_MEM_ACC)) ||
> 		    (yenta_search_res(socket, res, BRIDGE_MEM_MIN)))
>-

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] Simplify yenta code
  2007-10-06  4:26 [PATCH] Simplify yenta code Komuro
@ 2007-10-08 17:47 ` Linas Vepstas
  2007-10-13 22:36 ` [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC Komuro
  1 sibling, 0 replies; 23+ messages in thread
From: Linas Vepstas @ 2007-10-08 17:47 UTC (permalink / raw)
  To: Komuro; +Cc: linux-kernel

On Sat, Oct 06, 2007 at 01:26:01PM +0900, Komuro wrote:
> Hello,
> 
> Unfortunately, your patch is wrong,
> and does not results in the same run-time behaviour.

Yes, I thought I'd withdrawn it, as a monday-morning error.
If that wasn't clear .. NAK to my own patch.

--linas

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [NOT VERY SAFE]     [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-06  4:26 [PATCH] Simplify yenta code Komuro
  2007-10-08 17:47 ` Linas Vepstas
@ 2007-10-13 22:36 ` Komuro
  2007-10-13 22:52   ` David Miller
                     ` (2 more replies)
  1 sibling, 3 replies; 23+ messages in thread
From: Komuro @ 2007-10-13 22:36 UTC (permalink / raw)
  To: davem; +Cc: linux-kernel


Dear David

The patch "[TCP]: Set initial_ssthresh default to zero in Cubic and BIC."
is not very safe.

With this patch, ftp-transfer stops in my system.
(vsftpd-2.0.5-8)

Please revert this patch.


Best Regards
Komuro

>commit 66e1e3b20cbbf99da63e6c1af0fc6d39c2ed099a
>Author: David S. Miller <davem@sunset.davemloft.net>
>Date:   Wed Jun 13 01:03:53 2007 -0700
>
>    [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
>    
>    Because of the current default of 100, Cubic and BIC perform very
>    poorly compared to standard Reno.
>    
>    In the worst case, this change makes Cubic and BIC as aggressive as
>    Reno.  So this change should be very safe.
>    
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>
>diff --git a/net/ipv4/tcp_bic.c b/net/ipv4/tcp_bic.c
>index 281c9f9..dd9ef65 100644
>--- a/net/ipv4/tcp_bic.c
>+++ b/net/ipv4/tcp_bic.c
>@@ -29,7 +29,7 @@ static int fast_convergence = 1;
> static int max_increment = 16;
> static int low_window = 14;
> static int beta = 819;		/* = 819/1024 (BICTCP_BETA_SCALE) */
>-static int initial_ssthresh = 100;
>+static int initial_ssthresh;
> static int smooth_part = 20;
> 
> module_param(fast_convergence, int, 0644);
>diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
>index 1422448..ebfaac2 100644
>--- a/net/ipv4/tcp_cubic.c
>+++ b/net/ipv4/tcp_cubic.c
>@@ -29,7 +29,7 @@
> static int fast_convergence __read_mostly = 1;
> static int max_increment __read_mostly = 16;
> static int beta __read_mostly = 819;	/* = 819/1024 (BICTCP_BETA_SCALE) */
>-static int initial_ssthresh __read_mostly = 100;
>+static int initial_ssthresh __read_mostly;
> static int bic_scale __read_mostly = 41;
> static int tcp_friendliness __read_mostly = 1;
> 

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-13 22:36 ` [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC Komuro
@ 2007-10-13 22:52   ` David Miller
  2007-10-13 22:54     ` David Miller
  2007-10-14  1:02   ` Komuro
  2008-03-02 12:07   ` [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang Komuro
  2 siblings, 1 reply; 23+ messages in thread
From: David Miller @ 2007-10-13 22:52 UTC (permalink / raw)
  To: komurojun; +Cc: davem, linux-kernel, netdev

From: Komuro <komurojun@nifty.com>
Date: Sun, 14 Oct 2007 07:36:58 +0900

> 
> Dear David
> 
> The patch "[TCP]: Set initial_ssthresh default to zero in Cubic and BIC."
> is not very safe.
> 
> With this patch, ftp-transfer stops in my system.
> (vsftpd-2.0.5-8)
> 
> Please revert this patch.

No, I will not revert it with so little information, that would be a
knee-jerk reaction.

Let's anaylyze the problem first.  Please:

1) Send this report to the correct place, which is netdev@vger.kernel.org,
   so that the networking developers can analyze the bug.  Most of
   the core networking developers do not read linux-kernel so they
   did not see your report.

2) Provide a test case that the developers can use the precisely
   reproduce the problem.  Your problem may be dependant upon the
   remote system or infrastructure such as firewalls that sit between
   your machine and the remote one, so it may instead be useful
   to provide a tcpdump of the failing transfer.

I suspect some intermediate node, such as a firewall, is corrupting
your connection and causing the transfer to fail, and thus reverting
the BIC/CUBIC patch is just a workaround.

There are no other reports like your's and that change has been in
the tree for long enough to get substantial exposure.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-13 22:52   ` David Miller
@ 2007-10-13 22:54     ` David Miller
  0 siblings, 0 replies; 23+ messages in thread
From: David Miller @ 2007-10-13 22:54 UTC (permalink / raw)
  To: komurojun; +Cc: davem, linux-kernel, netdev

From: David Miller <davem@davemloft.net>
Date: Sat, 13 Oct 2007 15:52:11 -0700 (PDT)

> From: Komuro <komurojun@nifty.com>
> Date: Sun, 14 Oct 2007 07:36:58 +0900

BTW, even my reply didn't reach him, nifty.com reports "user unknown"
for him.

I really, truly, suspect therefore that he has other kinds of issues
at his site :-)

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [NOT VERY SAFE]     [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-13 22:36 ` [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC Komuro
  2007-10-13 22:52   ` David Miller
@ 2007-10-14  1:02   ` Komuro
  2007-10-14  2:38     ` David Miller
                       ` (2 more replies)
  2008-03-02 12:07   ` [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang Komuro
  2 siblings, 3 replies; 23+ messages in thread
From: Komuro @ 2007-10-14  1:02 UTC (permalink / raw)
  To: davem; +Cc: linux-kernel

Dear David

Actually, tcp_sk(sk)->snd_ssthresh is not initialized,
if initial_ssthresh is 0.

The patch should be

 static void bictcp_init(struct sock *sk)
 {
 	bictcp_reset(inet_csk_ca(sk));
-	if (initial_ssthresh)
-		tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
+
+	tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
 }

Best Regards
Komuro

> 
> Dear David
> 
> The patch "[TCP]: Set initial_ssthresh default to zero in Cubic and BIC."
> is not very safe.
> 
> With this patch, ftp-transfer stops in my system.
> (vsftpd-2.0.5-8)
> 
> Please revert this patch.
> 
> 
> Best Regards
> Komuro
> 
> >commit 66e1e3b20cbbf99da63e6c1af0fc6d39c2ed099a
> >Author: David S. Miller <davem@sunset.davemloft.net>
> >Date:   Wed Jun 13 01:03:53 2007 -0700
> >
> >    [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
> >    
> >    Because of the current default of 100, Cubic and BIC perform very
> >    poorly compared to standard Reno.
> >    
> >    In the worst case, this change makes Cubic and BIC as aggressive as
> >    Reno.  So this change should be very safe.
> >    
> >    Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> >diff --git a/net/ipv4/tcp_bic.c b/net/ipv4/tcp_bic.c
> >index 281c9f9..dd9ef65 100644
> >--- a/net/ipv4/tcp_bic.c
> >+++ b/net/ipv4/tcp_bic.c
> >@@ -29,7 +29,7 @@ static int fast_convergence = 1;
> > static int max_increment = 16;
> > static int low_window = 14;
> > static int beta = 819;		/* = 819/1024 (BICTCP_BETA_SCALE) */
> >-static int initial_ssthresh = 100;
> >+static int initial_ssthresh;
> > static int smooth_part = 20;
> > 
> > module_param(fast_convergence, int, 0644);
> >diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
> >index 1422448..ebfaac2 100644
> >--- a/net/ipv4/tcp_cubic.c
> >+++ b/net/ipv4/tcp_cubic.c
> >@@ -29,7 +29,7 @@
> > static int fast_convergence __read_mostly = 1;
> > static int max_increment __read_mostly = 16;
> > static int beta __read_mostly = 819;	/* = 819/1024 (BICTCP_BETA_SCALE) */
> >-static int initial_ssthresh __read_mostly = 100;
> >+static int initial_ssthresh __read_mostly;
> > static int bic_scale __read_mostly = 41;
> > static int tcp_friendliness __read_mostly = 1;
> > 


-- 
Komuro <komurojun@nifty.com>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-14  1:02   ` Komuro
@ 2007-10-14  2:38     ` David Miller
  2007-10-14  4:30       ` Jeff Garzik
  2007-10-14  4:28     ` Komuro
  2007-10-14 20:34     ` Stephen Hemminger
  2 siblings, 1 reply; 23+ messages in thread
From: David Miller @ 2007-10-14  2:38 UTC (permalink / raw)
  To: komurojun; +Cc: davem, linux-kernel

From: Komuro <komurojun@nifty.com>
Date: Sun, 14 Oct 2007 10:02:45 +0900

> Dear David
> 
> Actually, tcp_sk(sk)->snd_ssthresh is not initialized,
> if initial_ssthresh is 0.

Komuro, every single email I sent to you bounces with "user unknown",
I bet it is some spam filter or similar that doesn't like the
fact that I lack reverse DNS.

Can someone tell Komuro this side-band?  He also missed my
previous reply, which directed him to make his report on
netdev@vger.kernel.org which is very important.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [NOT VERY SAFE]     [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-14  1:02   ` Komuro
  2007-10-14  2:38     ` David Miller
@ 2007-10-14  4:28     ` Komuro
  2007-10-14  4:32       ` David Miller
  2007-10-14  4:53       ` Komuro
  2007-10-14 20:34     ` Stephen Hemminger
  2 siblings, 2 replies; 23+ messages in thread
From: Komuro @ 2007-10-14  4:28 UTC (permalink / raw)
  To: davem; +Cc: netdev, linux-kernel


Dear David

>Komuro, every single email I sent to you bounces with "user unknown",
>I bet it is some spam filter or similar that doesn't like the
>fact that I lack reverse DNS.

>From mailing-list-archive,
I can read your email.

Best Regards
Komuro

> Dear David
> 
> Actually, tcp_sk(sk)->snd_ssthresh is not initialized,
> if initial_ssthresh is 0.
> 
> The patch should be
> 
>  static void bictcp_init(struct sock *sk)
>  {
>  	bictcp_reset(inet_csk_ca(sk));
> -	if (initial_ssthresh)
> -		tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
> +
> +	tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
>  }
> 
> Best Regards
> Komuro
> 
> > 
> > Dear David
> > 
> > The patch "[TCP]: Set initial_ssthresh default to zero in Cubic and BIC."
> > is not very safe.
> > 
> > With this patch, ftp-transfer stops in my system.
> > (vsftpd-2.0.5-8)
> > 
> > Please revert this patch.
> > 
> > 
> > Best Regards
> > Komuro
> > 
> > >commit 66e1e3b20cbbf99da63e6c1af0fc6d39c2ed099a
> > >Author: David S. Miller <davem@sunset.davemloft.net>
> > >Date:   Wed Jun 13 01:03:53 2007 -0700
> > >
> > >    [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
> > >    
> > >    Because of the current default of 100, Cubic and BIC perform very
> > >    poorly compared to standard Reno.
> > >    
> > >    In the worst case, this change makes Cubic and BIC as aggressive as
> > >    Reno.  So this change should be very safe.
> > >    
> > >    Signed-off-by: David S. Miller <davem@davemloft.net>
> > >
> > >diff --git a/net/ipv4/tcp_bic.c b/net/ipv4/tcp_bic.c
> > >index 281c9f9..dd9ef65 100644
> > >--- a/net/ipv4/tcp_bic.c
> > >+++ b/net/ipv4/tcp_bic.c
> > >@@ -29,7 +29,7 @@ static int fast_convergence = 1;
> > > static int max_increment = 16;
> > > static int low_window = 14;
> > > static int beta = 819;		/* = 819/1024 (BICTCP_BETA_SCALE) */
> > >-static int initial_ssthresh = 100;
> > >+static int initial_ssthresh;
> > > static int smooth_part = 20;
> > > 
> > > module_param(fast_convergence, int, 0644);
> > >diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
> > >index 1422448..ebfaac2 100644
> > >--- a/net/ipv4/tcp_cubic.c
> > >+++ b/net/ipv4/tcp_cubic.c
> > >@@ -29,7 +29,7 @@
> > > static int fast_convergence __read_mostly = 1;
> > > static int max_increment __read_mostly = 16;
> > > static int beta __read_mostly = 819;	/* = 819/1024 (BICTCP_BETA_SCALE) */
> > >-static int initial_ssthresh __read_mostly = 100;
> > >+static int initial_ssthresh __read_mostly;
> > > static int bic_scale __read_mostly = 41;
> > > static int tcp_friendliness __read_mostly = 1;
> > > 
> 
> 
> -- 
> Komuro <komurojun@nifty.com>


-- 
Komuro <komurojun@nifty.com>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-14  2:38     ` David Miller
@ 2007-10-14  4:30       ` Jeff Garzik
  0 siblings, 0 replies; 23+ messages in thread
From: Jeff Garzik @ 2007-10-14  4:30 UTC (permalink / raw)
  To: David Miller; +Cc: komurojun, davem, linux-kernel, Komuro

David Miller wrote:
> From: Komuro <komurojun@nifty.com>
> Date: Sun, 14 Oct 2007 10:02:45 +0900
> 
>> Dear David
>>
>> Actually, tcp_sk(sk)->snd_ssthresh is not initialized,
>> if initial_ssthresh is 0.
> 
> Komuro, every single email I sent to you bounces with "user unknown",
> I bet it is some spam filter or similar that doesn't like the
> fact that I lack reverse DNS.
> 
> Can someone tell Komuro this side-band?  He also missed my
> previous reply, which directed him to make his report on
> netdev@vger.kernel.org which is very important.

I get bounces too, but Komuro <komurojun-mbn@nifty.com> seems to work.

	Jeff




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-14  4:28     ` Komuro
@ 2007-10-14  4:32       ` David Miller
  2007-10-14  4:53       ` Komuro
  1 sibling, 0 replies; 23+ messages in thread
From: David Miller @ 2007-10-14  4:32 UTC (permalink / raw)
  To: komurojun; +Cc: davem, netdev, linux-kernel

From: Komuro <komurojun@nifty.com>
Date: Sun, 14 Oct 2007 13:28:51 +0900

> 
> Dear David
> 
> >Komuro, every single email I sent to you bounces with "user unknown",
> >I bet it is some spam filter or similar that doesn't like the
> >fact that I lack reverse DNS.
> 
> >From mailing-list-archive,
> I can read your email.

Then why is your site sending everyone back bounces like the
following, when email is sent to you?

<komurojun@nifty.com>: host mx.nifty.com[202.248.238.10] said: 550 5.1.1
    <komurojun@nifty.com>... User unknown (in reply to RCPT TO command)

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [NOT VERY SAFE]     [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-14  4:28     ` Komuro
  2007-10-14  4:32       ` David Miller
@ 2007-10-14  4:53       ` Komuro
  2007-10-14  5:23         ` David Miller
  2007-10-15 12:59         ` Komuro
  1 sibling, 2 replies; 23+ messages in thread
From: Komuro @ 2007-10-14  4:53 UTC (permalink / raw)
  To: komurojun-mbn; +Cc: netdev, linux-kernel


Dear David

Sorry, my mailer's mail-address setting is wrong.


Best Regards
Komuro

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-14  4:53       ` Komuro
@ 2007-10-14  5:23         ` David Miller
  2007-10-15 12:59         ` Komuro
  1 sibling, 0 replies; 23+ messages in thread
From: David Miller @ 2007-10-14  5:23 UTC (permalink / raw)
  To: komurojun-mbn; +Cc: netdev, linux-kernel

From: Komuro <komurojun-mbn@nifty.com>
Date: Sun, 14 Oct 2007 13:53:56 +0900

> Sorry, my mailer's mail-address setting is wrong.

Thank you for fixing this :-)

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [NOT VERY SAFE]     [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-14  1:02   ` Komuro
  2007-10-14  2:38     ` David Miller
  2007-10-14  4:28     ` Komuro
@ 2007-10-14 20:34     ` Stephen Hemminger
  2 siblings, 0 replies; 23+ messages in thread
From: Stephen Hemminger @ 2007-10-14 20:34 UTC (permalink / raw)
  To: linux-kernel

On Sun, 14 Oct 2007 10:02:45 +0900
Komuro <komurojun@nifty.com> wrote:

> Dear David
> 
> Actually, tcp_sk(sk)->snd_ssthresh is not initialized,
> if initial_ssthresh is 0.
> 
> The patch should be
> 
>  static void bictcp_init(struct sock *sk)
>  {
>  	bictcp_reset(inet_csk_ca(sk));
> -	if (initial_ssthresh)
> -		tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
> +
> +	tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
>  }
>

In which case it is zero because that is the default value.

If you want to make arguments about sshtresh value, you need to provide
tcp traces of good vs problematic connection and get a good idea of
what the intermediate path and remote host OS is.  Since you are
the first to raise the issue, you will have to provide a lot of evidence
to overcome the developer suspicion that the problem is due to
buggy middle boxes, hardware or the other end.


-- 
Stephen Hemminger <shemminger@linux-foundation.org>


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [NOT VERY SAFE]     [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-14  4:53       ` Komuro
  2007-10-14  5:23         ` David Miller
@ 2007-10-15 12:59         ` Komuro
  2007-10-15 15:55           ` Stephen Hemminger
  1 sibling, 1 reply; 23+ messages in thread
From: Komuro @ 2007-10-15 12:59 UTC (permalink / raw)
  To: shemminger; +Cc: netdev, linux-kernel

Dear shemminger

>In which case it is zero because that is the default value.

The default value of snd_ssthresh is 0x7fffffff, isn't it?

[linux/net/ipv4/tcp_ipv4.c]
static int tcp_v4_init_sock(struct sock *sk)
...
        tp->snd_ssthresh = 0x7fffffff;  /* Infinity */
...

Best Regards
Komuro


> 
> Actually, tcp_sk(sk)->snd_ssthresh is not initialized,
> if initial_ssthresh is 0.
> 
> The patch should be
> 
>  static void bictcp_init(struct sock *sk)
>  {
>  	bictcp_reset(inet_csk_ca(sk));
> -	if (initial_ssthresh)
> -		tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
> +
> +	tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
>  }
>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [NOT VERY SAFE]     [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
  2007-10-15 12:59         ` Komuro
@ 2007-10-15 15:55           ` Stephen Hemminger
  0 siblings, 0 replies; 23+ messages in thread
From: Stephen Hemminger @ 2007-10-15 15:55 UTC (permalink / raw)
  To: Komuro; +Cc: shemminger, netdev, linux-kernel

On Mon, 15 Oct 2007 21:59:49 +0900
Komuro <komurojun-mbn@nifty.com> wrote:

> Dear shemminger
> 
> >In which case it is zero because that is the default value.
> 
> The default value of snd_ssthresh is 0x7fffffff, isn't it?
> 
> [linux/net/ipv4/tcp_ipv4.c]
> static int tcp_v4_init_sock(struct sock *sk)
> ...
>         tp->snd_ssthresh = 0x7fffffff;  /* Infinity */
> ...
> 
> Best Regards
> Komuro
> 
> 

Yes that value means that TCP stays in slow start until the first loss.
This makes TCP behave as expected in the RFC's.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [BUG  kernel 2.6.25-rc3  IPV6]  ping6 -I eth0 ff02::1 causes system hang.
  2007-10-13 22:36 ` [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC Komuro
  2007-10-13 22:52   ` David Miller
  2007-10-14  1:02   ` Komuro
@ 2008-03-02 12:07   ` Komuro
  2008-03-02 12:27     ` YOSHIFUJI Hideaki / 吉藤英明
                       ` (3 more replies)
  2 siblings, 4 replies; 23+ messages in thread
From: Komuro @ 2008-03-02 12:07 UTC (permalink / raw)
  To: linux-kernel

Hi,

On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
after sending several multicast ping packet.

>ping6 -I eth0 ff02::1 

This problem does not happen on kernel 2.6.24.
(does not depend on NIC)


Best Regards
Komuro



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang.
  2008-03-02 12:07   ` [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang Komuro
@ 2008-03-02 12:27     ` YOSHIFUJI Hideaki / 吉藤英明
  2008-03-04 17:49       ` Brian Haley
  2008-03-03 22:06     ` Komuro
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 23+ messages in thread
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2008-03-02 12:27 UTC (permalink / raw)
  To: komurojun-mbn; +Cc: netdev

Switch to netdev.

In article <20080302210716.69727582.komurojun-mbn@nifty.com> (at Sun, 2 Mar 2008 21:07:16 +0900), Komuro <komurojun-mbn@nifty.com> says:

> On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
> after sending several multicast ping packet.
> 
> >ping6 -I eth0 ff02::1 
> 
> This problem does not happen on kernel 2.6.24.
> (does not depend on NIC)

Hmm, I've never seen this on our testlab.  Anyone else?
It would be great if you have chance to bisect it...

--yoshfuji

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Re: [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang.
  2008-03-02 12:07   ` [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang Komuro
  2008-03-02 12:27     ` YOSHIFUJI Hideaki / 吉藤英明
@ 2008-03-03 22:06     ` Komuro
  2008-03-04  7:40     ` Andrew Morton
  2008-03-08  4:44     ` Komuro
  3 siblings, 0 replies; 23+ messages in thread
From: Komuro @ 2008-03-03 22:06 UTC (permalink / raw)
  To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev


Hi,

CONFIG_IPV6=y
but other IPV6 option is all not set.
in my configuration(.config)


>It would be great if you have chance to bisect it...

I don't have enough time on week-days ...


Best Regards
Komuro


>
>Switch to netdev.
>
>In article <20080302210716.69727582.komurojun-mbn@nifty.com> (at Sun, 2 Mar 2
008 21:07:16 +0900), Komuro <komurojun-mbn@nifty.com> says:
>
>> On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
>> after sending several multicast ping packet.
>> 
>> >ping6 -I eth0 ff02::1 
>> 
>> This problem does not happen on kernel 2.6.24.
>> (does not depend on NIC)
>
>Hmm, I've never seen this on our testlab.  Anyone else?
>It would be great if you have chance to bisect it...
>
>--yoshfuji


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [BUG  kernel 2.6.25-rc3  IPV6]  ping6 -I eth0 ff02::1 causes system hang.
  2008-03-02 12:07   ` [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang Komuro
  2008-03-02 12:27     ` YOSHIFUJI Hideaki / 吉藤英明
  2008-03-03 22:06     ` Komuro
@ 2008-03-04  7:40     ` Andrew Morton
  2008-03-08  4:44     ` Komuro
  3 siblings, 0 replies; 23+ messages in thread
From: Andrew Morton @ 2008-03-04  7:40 UTC (permalink / raw)
  To: Komuro; +Cc: linux-kernel, netdev

On Sun, 2 Mar 2008 21:07:16 +0900 Komuro <komurojun-mbn@nifty.com> wrote:

> Hi,
> 
> On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
> after sending several multicast ping packet.
> 
> >ping6 -I eth0 ff02::1 
> 
> This problem does not happen on kernel 2.6.24.
> (does not depend on NIC)
> 

Let's cc the netdev list..

I tried it with 2.6.25-rc3-mm1 and got:

t61p:/home/akpm> ping6 -I eth0 ff02::1 
PING ff02::1(ff02::1) from fe80::215:58ff:fec6:dc4b eth0: 56 data bytes
64 bytes from fe80::215:58ff:fec6:dc4b: icmp_seq=1 ttl=64 time=0.059 ms
64 bytes from fe80::219:d1ff:fe04:8f42: icmp_seq=1 ttl=64 time=1.74 ms (DUP!)
64 bytes from fe80::214:51ff:fe67:55ef: icmp_seq=1 ttl=64 time=2.42 ms (DUP!)
64 bytes from fe80::202:b3ff:fe8f:a731: icmp_seq=1 ttl=64 time=4.72 ms (DUP!)
64 bytes from fe80::211:24ff:fe71:cbe4: icmp_seq=1 ttl=64 time=451 ms (DUP!)
64 bytes from fe80::215:58ff:fec6:dc4b: icmp_seq=2 ttl=64 time=0.090 ms
64 bytes from fe80::202:b3ff:fe8f:a731: icmp_seq=2 ttl=64 time=0.499 ms (DUP!)
64 bytes from fe80::214:51ff:fe67:55ef: icmp_seq=2 ttl=64 time=0.542 ms (DUP!)
64 bytes from fe80::219:d1ff:fe04:8f42: icmp_seq=2 ttl=64 time=0.576 ms (DUP!)
64 bytes from fe80::211:24ff:fe71:cbe4: icmp_seq=2 ttl=64 time=0.609 ms (DUP!)
64 bytes from fe80::215:58ff:fec6:dc4b: icmp_seq=3 ttl=64 time=0.086 ms
64 bytes from fe80::202:b3ff:fe8f:a731: icmp_seq=3 ttl=64 time=0.484 ms (DUP!)
64 bytes from fe80::214:51ff:fe67:55ef: icmp_seq=3 ttl=64 time=0.527 ms (DUP!)
64 bytes from fe80::219:d1ff:fe04:8f42: icmp_seq=3 ttl=64 time=0.561 ms (DUP!)
64 bytes from fe80::211:24ff:fe71:cbe4: icmp_seq=3 ttl=64 time=0.595 ms (DUP!)
64 bytes from fe80::215:58ff:fec6:dc4b: icmp_seq=4 ttl=64 time=0.084 ms
64 bytes from fe80::202:b3ff:fe8f:a731: icmp_seq=4 ttl=64 time=0.314 ms (DUP!)
64 bytes from fe80::214:51ff:fe67:55ef: icmp_seq=4 ttl=64 time=0.352 ms (DUP!)
64 bytes from fe80::211:24ff:fe71:cbe4: icmp_seq=4 ttl=64 time=0.386 ms (DUP!)
64 bytes from fe80::219:d1ff:fe04:8f42: icmp_seq=4 ttl=64 time=0.420 ms (DUP!)
64 bytes from fe80::215:58ff:fec6:dc4b: icmp_seq=5 ttl=64 time=0.106 ms
64 bytes from fe80::202:b3ff:fe8f:a731: icmp_seq=5 ttl=64 time=0.551 ms (DUP!)
64 bytes from fe80::214:51ff:fe67:55ef: icmp_seq=5 ttl=64 time=0.593 ms (DUP!)
64 bytes from fe80::219:d1ff:fe04:8f42: icmp_seq=5 ttl=64 time=0.627 ms (DUP!)
64 bytes from fe80::211:24ff:fe71:cbe4: icmp_seq=5 ttl=64 time=0.661 ms (DUP!)
^C
--- ff02::1 ping statistics ---
5 packets transmitted, 5 received, +20 duplicates, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.059/18.754/451.249/88.287 ms



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang.
  2008-03-02 12:27     ` YOSHIFUJI Hideaki / 吉藤英明
@ 2008-03-04 17:49       ` Brian Haley
  0 siblings, 0 replies; 23+ messages in thread
From: Brian Haley @ 2008-03-04 17:49 UTC (permalink / raw)
  To: YOSHIFUJI Hideaki / ????; +Cc: komurojun-mbn, netdev

>> On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
>> after sending several multicast ping packet.
>>
>>> ping6 -I eth0 ff02::1 
>> This problem does not happen on kernel 2.6.24.
>> (does not depend on NIC)
> 
> Hmm, I've never seen this on our testlab.  Anyone else?

Not here.  I tried just CONFIG_IPV6=y as well.

-Brian

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [BUG  kernel 2.6.25-rc3  IPV6]  ping6 -I eth0 ff02::1 causes system hang.
  2008-03-02 12:07   ` [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang Komuro
                       ` (2 preceding siblings ...)
  2008-03-04  7:40     ` Andrew Morton
@ 2008-03-08  4:44     ` Komuro
  2008-03-08  5:20       ` Komuro
  2008-03-08 11:56       ` David Miller
  3 siblings, 2 replies; 23+ messages in thread
From: Komuro @ 2008-03-08  4:44 UTC (permalink / raw)
  To: netdev; +Cc: linux-kernel, yoshfuji

Hi,

>Hmm, I've never seen this on our testlab.  Anyone else?

Could you send 20(twenty) or more ping packets?


>It would be great if you have chance to bisect it...On Sun, 2 Mar 2008 21:07:16 +0900

The bad commit is below.

69cc64d8d92bf852f933e90c888dfff083bd4fc9 is first bad commit
commit 69cc64d8d92bf852f933e90c888dfff083bd4fc9
Author: David S. Miller <davem@davemloft.net>
Date:   Mon Feb 11 21:45:44 2008 -0800

    [NDISC]: Fix race in generic address resolution

    Frank Blaschka provided the bug report and the initial suggested fix
    for this bug.  He also validated this version of this fix.




> Hi,
> 
> On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
> after sending several multicast ping packet.
> 
> >ping6 -I eth0 ff02::1 
> 
> This problem does not happen on kernel 2.6.24.
> (does not depend on NIC)

 
Best Regards
Komuro
 
 


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [BUG  kernel 2.6.25-rc3  IPV6]  ping6 -I eth0 ff02::1 causes system hang.
  2008-03-08  4:44     ` Komuro
@ 2008-03-08  5:20       ` Komuro
  2008-03-08 11:56       ` David Miller
  1 sibling, 0 replies; 23+ messages in thread
From: Komuro @ 2008-03-08  5:20 UTC (permalink / raw)
  To: Komuro; +Cc: netdev, linux-kernel, yoshfuji


Hi,

sorry, this problem exist on 2.6.25-rc2.
but it seems to be fixed on 2.6.25-rc3.


Best Regards
Komuro

> Hi,
> 
> >Hmm, I've never seen this on our testlab.  Anyone else?
> 
> Could you send 20(twenty) or more ping packets?
> 
> 
> >It would be great if you have chance to bisect it...On Sun, 2 Mar 2008 21:07:16 +0900
> 
> The bad commit is below.
> 
> 69cc64d8d92bf852f933e90c888dfff083bd4fc9 is first bad commit
> commit 69cc64d8d92bf852f933e90c888dfff083bd4fc9
> Author: David S. Miller <davem@davemloft.net>
> Date:   Mon Feb 11 21:45:44 2008 -0800
> 
>     [NDISC]: Fix race in generic address resolution
> 
>     Frank Blaschka provided the bug report and the initial suggested fix
>     for this bug.  He also validated this version of this fix.
> 
> 
> 
> 
> > Hi,
> > 
> > On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
> > after sending several multicast ping packet.
> > 
> > >ping6 -I eth0 ff02::1 
> > 
> > This problem does not happen on kernel 2.6.24.
> > (does not depend on NIC)
> 
>  
> Best Regards
> Komuro
>  
>  
> 


-- 
Komuro <komurojun-mbn@nifty.com>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang.
  2008-03-08  4:44     ` Komuro
  2008-03-08  5:20       ` Komuro
@ 2008-03-08 11:56       ` David Miller
  1 sibling, 0 replies; 23+ messages in thread
From: David Miller @ 2008-03-08 11:56 UTC (permalink / raw)
  To: komurojun-mbn; +Cc: netdev, linux-kernel, yoshfuji

From: Komuro <komurojun-mbn@nifty.com>
Date: Sat, 8 Mar 2008 13:44:10 +0900

> The bad commit is below.
> 
> 69cc64d8d92bf852f933e90c888dfff083bd4fc9 is first bad commit
> commit 69cc64d8d92bf852f933e90c888dfff083bd4fc9
> Author: David S. Miller <davem@davemloft.net>
> Date:   Mon Feb 11 21:45:44 2008 -0800
> 
>     [NDISC]: Fix race in generic address resolution
> 
>     Frank Blaschka provided the bug report and the initial suggested fix
>     for this bug.  He also validated this version of this fix.

This was a known bad commit and got reverted more than a week ago.

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2008-03-08 11:56 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-06  4:26 [PATCH] Simplify yenta code Komuro
2007-10-08 17:47 ` Linas Vepstas
2007-10-13 22:36 ` [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC Komuro
2007-10-13 22:52   ` David Miller
2007-10-13 22:54     ` David Miller
2007-10-14  1:02   ` Komuro
2007-10-14  2:38     ` David Miller
2007-10-14  4:30       ` Jeff Garzik
2007-10-14  4:28     ` Komuro
2007-10-14  4:32       ` David Miller
2007-10-14  4:53       ` Komuro
2007-10-14  5:23         ` David Miller
2007-10-15 12:59         ` Komuro
2007-10-15 15:55           ` Stephen Hemminger
2007-10-14 20:34     ` Stephen Hemminger
2008-03-02 12:07   ` [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang Komuro
2008-03-02 12:27     ` YOSHIFUJI Hideaki / 吉藤英明
2008-03-04 17:49       ` Brian Haley
2008-03-03 22:06     ` Komuro
2008-03-04  7:40     ` Andrew Morton
2008-03-08  4:44     ` Komuro
2008-03-08  5:20       ` Komuro
2008-03-08 11:56       ` David Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.