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 <[email protected]>
Cc: Dominik Brodowski <[email protected]>
----
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)))
On Mon, Oct 01, 2007 at 01:41:15PM -0500, Linas Vepstas wrote:
> - 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)))
Are BRIDGE_IO_MAX and BRIDGE_MEM_MAX guaranteed to be the same?
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On Mon, Oct 01, 2007 at 12:56:55PM -0600, Matthew Wilcox wrote:
>
> Are BRIDGE_IO_MAX and BRIDGE_MEM_MAX guaranteed to be the same?
@#$%^&*. Red-faced, I withdraw the patch. Must be cross-eyed on
a Monday morning. Sorry.
--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 <[email protected]>
>Cc: Dominik Brodowski <[email protected]>
>
>----
> 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)))
>-
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
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 <[email protected]>
>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 <[email protected]>
>
>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;
>
From: Komuro <[email protected]>
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 [email protected],
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.
From: David Miller <[email protected]>
Date: Sat, 13 Oct 2007 15:52:11 -0700 (PDT)
> From: Komuro <[email protected]>
> 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 :-)
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 <[email protected]>
> >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 <[email protected]>
> >
> >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 <[email protected]>
From: Komuro <[email protected]>
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
[email protected] which is very important.
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 <[email protected]>
> > >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 <[email protected]>
> > >
> > >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 <[email protected]>
--
Komuro <[email protected]>
David Miller wrote:
> From: Komuro <[email protected]>
> 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
> [email protected] which is very important.
I get bounces too, but Komuro <[email protected]> seems to work.
Jeff
From: Komuro <[email protected]>
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?
<[email protected]>: host mx.nifty.com[202.248.238.10] said: 550 5.1.1
<[email protected]>... User unknown (in reply to RCPT TO command)
Dear David
Sorry, my mailer's mail-address setting is wrong.
Best Regards
Komuro
From: Komuro <[email protected]>
Date: Sun, 14 Oct 2007 13:53:56 +0900
> Sorry, my mailer's mail-address setting is wrong.
Thank you for fixing this :-)
On Sun, 14 Oct 2007 10:02:45 +0900
Komuro <[email protected]> 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 <[email protected]>
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;
> }
>
On Mon, 15 Oct 2007 21:59:49 +0900
Komuro <[email protected]> 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 <[email protected]>
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
On Sun, 2 Mar 2008 21:07:16 +0900 Komuro <[email protected]> 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
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 <[email protected]>
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
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 <[email protected]>
> 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 <[email protected]>
From: Komuro <[email protected]>
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 <[email protected]>
> 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.