From owner-netdev@oss.sgi.com Sun Oct  1 08:35:40 2000
Received:  by oss.sgi.com id <S42239AbQJAPfa>;
	Sun, 1 Oct 2000 08:35:30 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:1543 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42232AbQJAPeu>;
	Sun, 1 Oct 2000 08:34:50 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA09585; Sun, 1 Oct 2000 19:33:54 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010011533.TAA09585@ms2.inr.ac.ru>
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
To:     andrewm@uow.EDU.AU (Andrew Morton)
Date:   Sun, 1 Oct 2000 19:33:54 +0400 (MSK DST)
Cc:     ak@muc.de (Andi Kleen), davem@redhat.com (Dave Miller),
        netdev@oss.sgi.com
In-Reply-To: <39C9F123.D8FA4F68@uow.edu.au> from "Andrew Morton" at Sep 21, 0 03:45:00 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 394       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Yes.  On 2.4 (at least) there is nothing to prevent the driver's ioctl()
> function from running on two or more CPUs simultaneously.

I apologize, the reply is late a bit.

However, I have to remind that open/close/ioctl __are__ serialized
with global semaphore.

To Andi: BKL is fully useless here, just because these calls are allowed
to sleep.

The problem does not exist.

Alexey

From owner-netdev@oss.sgi.com Sun Oct  1 08:59:00 2000
Received:  by oss.sgi.com id <S42288AbQJAP6u>;
	Sun, 1 Oct 2000 08:58:50 -0700
Received: from isis.its.uow.edu.au ([130.130.68.21]:1664 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42232AbQJAP60>;
	Sun, 1 Oct 2000 08:58:26 -0700
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by isis.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id CAA15365
	for <netdev@oss.sgi.com>; Mon, 2 Oct 2000 02:57:50 +1100 (EST)
Message-ID: <39D75F78.492E2CA5@uow.edu.au>
Date:   Mon, 02 Oct 2000 02:59:52 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: [patch] tcp_tw in 2.4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

A couple of problems here..


* tcp_init() wants to set sysctl_tcp_max_tw_buckets to 180,000.  This
seems too high (Andi says 22 megs).  I think the patch here is more
consistent.

* tcp_twkill() can consume a huge amount of time if it has enough
connections to deal with.  When running lmbench I have observed it
killing 2,500 connections in a single pass, which means we spend 15
milliseconds in the timer handler.  This is crazy.

So I just kill a hundred and then reschedule the timer to run in a
couple of jiffies time.  The downside: this limits the tw reaping to
2,500 connections per second.  But I don't see a DoS opportunity here.



--- linux-2.4.0-test9-pre7/net/ipv4/tcp.c	Tue Sep 26 21:45:33 2000
+++ linux-akpm/net/ipv4/tcp.c	Mon Oct  2 02:44:59 2000
@@ -2438,7 +2438,7 @@
 	if (order > 4) {
 		sysctl_local_port_range[0] = 32768;
 		sysctl_local_port_range[1] = 61000;
-		sysctl_tcp_max_tw_buckets = 180000;
+		sysctl_tcp_max_tw_buckets <<= 1;
 		sysctl_tcp_max_orphans = 4096<<(order-4);
 		sysctl_max_syn_backlog = 1024;
 	} else if (order < 3) {
--- linux-2.4.0-test9-pre7/net/ipv4/tcp_minisocks.c	Tue Sep 26 21:45:33 2000
+++ linux-akpm/net/ipv4/tcp_minisocks.c	Mon Oct  2 02:15:02 2000
@@ -434,6 +434,7 @@
 {
 	struct tcp_tw_bucket *tw;
 	int killed = 0;
+	int max_killed = 0;
 
 	/* NOTE: compare this to previous version where lock
 	 * was released after detaching chain. It was racy,
@@ -447,6 +448,13 @@
 		goto out;
 
 	while((tw = tcp_tw_death_row[tcp_tw_death_row_slot]) != NULL) {
+
+		/* This loop takes ~6 usecs per iteration. */
+		if (killed > 100) {
+			max_killed = 1;
+			break;
+		}
+
 		tcp_tw_death_row[tcp_tw_death_row_slot] = tw->next_death;
 		tw->pprev_death = NULL;
 		spin_unlock(&tw_death_lock);
@@ -457,12 +465,19 @@
 		killed++;
 
 		spin_lock(&tw_death_lock);
+
+	}
+
+	if (max_killed) {	/* More to do: do it soon */
+		mod_timer(&tcp_tw_timer, jiffies+2);
+	} else {
+		tcp_tw_death_row_slot =
+			((tcp_tw_death_row_slot + 1) & (TCP_TWKILL_SLOTS - 1));
+	
+		if ((tcp_tw_count -= killed) != 0)
+			mod_timer(&tcp_tw_timer, jiffies+TCP_TWKILL_PERIOD);
 	}
-	tcp_tw_death_row_slot =
-		((tcp_tw_death_row_slot + 1) & (TCP_TWKILL_SLOTS - 1));
 
-	if ((tcp_tw_count -= killed) != 0)
-		mod_timer(&tcp_tw_timer, jiffies+TCP_TWKILL_PERIOD);
 	net_statistics[smp_processor_id()*2].TimeWaited += killed;
 out:
 	spin_unlock(&tw_death_lock);

From owner-netdev@oss.sgi.com Sun Oct  1 09:46:59 2000
Received:  by oss.sgi.com id <S42406AbQJAQqu>;
	Sun, 1 Oct 2000 09:46:50 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:18951 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42232AbQJAQq2>;
	Sun, 1 Oct 2000 09:46:28 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA09976; Sun, 1 Oct 2000 20:45:36 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010011645.UAA09976@ms2.inr.ac.ru>
Subject: Re: [patch] tcp_tw in 2.4
To:     andrewm@uow.EDU.AU (Andrew Morton)
Date:   Sun, 1 Oct 2000 20:45:36 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <39D75F78.492E2CA5@uow.edu.au> from "Andrew Morton" at Oct 1, 0 08:15:01 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 1148      
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> * tcp_init() wants to set sysctl_tcp_max_tw_buckets to 180,000.  This
> seems too high (Andi says 22 megs).  I think the patch here is more
> consistent.

For machine with 256MB it is not very big number.

Failure to create tw bucket is hard bug. Default value is to be so high
as possible.


> * tcp_twkill() can consume a huge amount of time if it has enough
> connections to deal with.  When running lmbench I have observed it
> killing 2,500 connections in a single pass, which means we spend 15
> milliseconds in the timer handler.  This is crazy.

If you expect of machine doing 700 conn/sec superb latency,
you expect an impossible thing.

We do much more particularly because the work is batched, when it is possible.

If you want to do sound recording on your web server,
it is better to increase granularity of tw calendar.


> So I just kill a hundred and then reschedule the timer to run in a
> couple of jiffies time.  The downside: this limits the tw reaping to
> 2,500 connections per second.

You simply limited your power by 2500 conn/sec, not more.
We must destroy buckets with the rate, which they are created.

Alexey

From owner-netdev@oss.sgi.com Sun Oct  1 13:03:23 2000
Received:  by oss.sgi.com id <S42430AbQJAUDE>;
	Sun, 1 Oct 2000 13:03:04 -0700
Received: from colin.muc.de ([193.149.48.1]:26895 "HELO colin.muc.de")
	by oss.sgi.com with SMTP id <S42232AbQJAUCh>;
	Sun, 1 Oct 2000 13:02:37 -0700
Received: by colin.muc.de id <140556-3>; Sun, 1 Oct 2000 22:01:31 +0200
Message-ID: <20001001220124.33226@colin.muc.de>
From:   Andi Kleen <ak@muc.de>
To:     kuznet@ms2.inr.ac.ru
Cc:     Andrew Morton <andrewm@uow.EDU.AU>, Andi Kleen <ak@muc.de>,
        Dave Miller <davem@redhat.com>, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
References: <39C9F123.D8FA4F68@uow.edu.au> <200010011533.TAA09585@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88e
In-Reply-To: <200010011533.TAA09585@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Sun, Oct 01, 2000 at 05:39:21PM +0200
Date:   Sun, 1 Oct 2000 22:01:25 +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sun, Oct 01, 2000 at 05:39:21PM +0200, kuznet@ms2.inr.ac.ru wrote:
> Hello!
> 
> > Yes.  On 2.4 (at least) there is nothing to prevent the driver's ioctl()
> > function from running on two or more CPUs simultaneously.
> 
> I apologize, the reply is late a bit.
> 
> However, I have to remind that open/close/ioctl __are__ serialized
> with global semaphore.
> 
> To Andi: BKL is fully useless here, just because these calls are allowed
> to sleep.

Of course it can sleep, in this case they have to lock themselves. With the
BKL it would at least not be worse than in 2.2.

[overall I think drivers/net/* is full of holes there, and 2.4 just made it much
worse]


-Andi

From owner-netdev@oss.sgi.com Mon Oct  2 00:41:55 2000
Received:  by oss.sgi.com id <S42435AbQJBHlf>;
	Mon, 2 Oct 2000 00:41:35 -0700
Received: from mandrakesoft.mandrakesoft.com ([216.71.84.35]:42841 "EHLO
        mandrakesoft.mandrakesoft.com") by oss.sgi.com with ESMTP
	id <S42232AbQJBHlH>; Mon, 2 Oct 2000 00:41:07 -0700
Received: from localhost (jgarzik@localhost)
	by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with SMTP id CAA08062;
	Mon, 2 Oct 2000 02:39:43 -0500
Date:   Mon, 2 Oct 2000 02:39:43 -0500 (CDT)
From:   Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com>
To:     Andi Kleen <ak@muc.de>
cc:     kuznet@ms2.inr.ac.ru, Andrew Morton <andrewm@uow.EDU.AU>,
        Dave Miller <davem@redhat.com>, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
In-Reply-To: <20001001220124.33226@colin.muc.de>
Message-ID: <Pine.LNX.3.96.1001002023849.27884G-100000@mandrakesoft.mandrakesoft.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sun, 1 Oct 2000, Andi Kleen wrote:
> [overall I think drivers/net/* is full of holes there, and 2.4 just made it much
> worse]

Please don't just say stuff like this and then run off.

As one of the few people who apparently cares about drivers/net, I would
like fix this shit!

Do tell...   I'm all ears.

	Jeff






From owner-netdev@oss.sgi.com Mon Oct  2 03:02:36 2000
Received:  by oss.sgi.com id <S42425AbQJBKCR>;
	Mon, 2 Oct 2000 03:02:17 -0700
Received: from sunsite.ms.mff.cuni.cz ([195.113.19.66]:17673 "EHLO
        sunsite.ms.mff.cuni.cz") by oss.sgi.com with ESMTP
	id <S42232AbQJBKBp>; Mon, 2 Oct 2000 03:01:45 -0700
Received: (from jj@localhost)
	by sunsite.ms.mff.cuni.cz (8.9.3/8.9.3) id MAA32542;
	Mon, 2 Oct 2000 12:03:49 +0200
Date:   Mon, 2 Oct 2000 12:03:49 +0200
From:   Jakub Jelinek <jakub@redhat.com>
To:     "David S. Miller" <davem@redhat.com>, kuznet@ms2.inr.ac.ru,
        ak@muc.de
Cc:     netdev@oss.sgi.com
Subject: socklen_t instead of size_t in struct cmsghdr
Message-ID: <20001002120349.L9588@sunsite.ms.mff.cuni.cz>
Reply-To: Jakub Jelinek <jakub@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi!

Would it be possible to change

--- linux/include/linux/socket.h.jj	Tue Sep 26 12:09:51 2000
+++ linux/include/linux/socket.h	Mon Oct  2 11:10:15 2000
@@ -47,7 +47,11 @@ struct msghdr {
  */
 
 struct cmsghdr {
+#if defined(__alpha__)
 	__kernel_size_t	cmsg_len;	/* data byte count, including hdr */
+#else
+	unsigned int	cmsg_len;	/* socklen_t everywhere but on Alpha */
+#endif
         int		cmsg_level;	/* originating protocol */
         int		cmsg_type;	/* protocol-specific type */
 };

and kill a lot of cmsg32 translation stuff from sys_sparc32.c and
sys_ia32.c?
E.g. Solaris defines cmsg_len as socklen_t and even Linux man page for
recvmsg defines it that way as well.
Sparc 64bit userland can definitely survive that change, I don't know if
ia64 can change it as well (and recompile everything), but as I think
everyone will have to recompile everything for glibc 2.2 anyway...

Below is an excerpt from my mail to libc-hacker:

> The problem is slightly different - it is in the cmsghdr structure
> definition in the Linux kernel and SPARC 32<->64bit translation layer.
> cmsghdr is defined as size_t; int; int while on e.g. on Solaris it is
> socklen_t; int; int which would simplify things a lot (because unlike size_t
> socklen_t does not differ between 64bit kernel and 32bit userland).
> The 32<->64bit translation layer (sys_sparc32.c) unfortunately unless it
> wants to suck really badly has to do the uint64_t;int;int ->
> uint32_t;int;int cmsghdr translation in userland and at the moment it does
> so in situ.
> So, I think we basically have 3 options:
> - hack around it in H.J's patch so that we always give some space in the
> msg_control buffer (other places in glibc use stuff like CMSG_SPACE() to
> calculate msg_controllen for recvmsg and they always seem to give space for
> the in situ translation).
> - hack the sys32_recvmsg translation so that it does not do the 32<->64bit
> msg_control translation in situ, but instead e.g. allocates a msg_controllen
> * 1.5 area off the userland %sp (and decrements it temporarily).
> - change cmsghdr definition at least on sparc64 (maybe ia64, mips64, k8) to
> socklen_t and kill all the ugly translation.

	Jakub

From owner-netdev@oss.sgi.com Mon Oct  2 08:07:10 2000
Received:  by oss.sgi.com id <S42444AbQJBPGu>;
	Mon, 2 Oct 2000 08:06:50 -0700
Received: from brutus.conectiva.com.br ([200.250.58.146]:20213 "HELO
        brinquedo.distro.conectiva") by oss.sgi.com with SMTP
	id <S42319AbQJBPGZ>; Mon, 2 Oct 2000 08:06:25 -0700
Received: by brinquedo.distro.conectiva (Postfix, from userid 501)
	id D3AD9273C; Mon,  2 Oct 2000 12:11:32 -0200 (BRST)
Date:   Mon, 2 Oct 2000 12:11:32 -0200
From:   Arnaldo Carvalho de Melo <acme@conectiva.com.br>
To:     Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com>
Cc:     Andi Kleen <ak@muc.de>, kuznet@ms2.inr.ac.ru,
        Andrew Morton <andrewm@uow.EDU.AU>,
        Dave Miller <davem@redhat.com>, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
Message-ID: <20001002121132.A1389@conectiva.com.br>
References: <20001001220124.33226@colin.muc.de> <Pine.LNX.3.96.1001002023849.27884G-100000@mandrakesoft.mandrakesoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.3.96.1001002023849.27884G-100000@mandrakesoft.mandrakesoft.com>; from jgarzik@mandrakesoft.mandrakesoft.com on Mon, Oct 02, 2000 at 02:39:43AM -0500
X-Url:  http://advogato.org/person/acme
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Em Mon, Oct 02, 2000 at 02:39:43AM -0500, Jeff Garzik escreveu:
> On Sun, 1 Oct 2000, Andi Kleen wrote:
> > [overall I think drivers/net/* is full of holes there, and 2.4 just made it much
> > worse]
> 
> Please don't just say stuff like this and then run off.
> 
> As one of the few people who apparently cares about drivers/net, I would
> like fix this shit!
> 
> Do tell...   I'm all ears.

yap, I have space in my TODO list :)

- Arnaldo

From owner-netdev@oss.sgi.com Mon Oct  2 09:18:11 2000
Received:  by oss.sgi.com id <S42424AbQJBQSB>;
	Mon, 2 Oct 2000 09:18:01 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:29968 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42232AbQJBQRd>;
	Mon, 2 Oct 2000 09:17:33 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA24010; Mon, 2 Oct 2000 20:16:11 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010021616.UAA24010@ms2.inr.ac.ru>
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
To:     jgarzik@mandrakesoft.mandrakesoft.com (Jeff Garzik)
Date:   Mon, 2 Oct 2000 20:16:11 +0400 (MSK DST)
Cc:     ak@muc.de, andrewm@uow.EDU.AU, davem@redhat.com, netdev@oss.sgi.com
In-Reply-To: <Pine.LNX.3.96.1001002023849.27884G-100000@mandrakesoft.mandrakesoft.com> from "Jeff Garzik" at Oct 2, 0 02:39:43 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 94        
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Do tell...   I'm all ears.

Relax. 8)

2.4 did not add new holes, actually.

Alexey

From owner-netdev@oss.sgi.com Mon Oct  2 09:40:51 2000
Received:  by oss.sgi.com id <S42232AbQJBQkb>;
	Mon, 2 Oct 2000 09:40:31 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:13329 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42440AbQJBQj7>;
	Mon, 2 Oct 2000 09:39:59 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA24172; Mon, 2 Oct 2000 20:38:57 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010021638.UAA24172@ms2.inr.ac.ru>
Subject: Re: socklen_t instead of size_t in struct cmsghdr
To:     jakub@redhat.com
Date:   Mon, 2 Oct 2000 20:38:57 +0400 (MSK DST)
Cc:     davem@redhat.com, ak@muc.de, netdev@oss.sgi.com
In-Reply-To: <20001002120349.L9588@sunsite.ms.mff.cuni.cz> from "Jakub Jelinek" at Oct 2, 0 12:03:49 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 765       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Would it be possible to change

Shit! The same story is with all the struct msghdr.


> Sparc 64bit userland can definitely survive that change,

Then change it. Only together with msghdr. Types of msg_namelen,
msg_controllen and cmsg_len must coincide and be socklen_t.
Changing only cmsg_len you will create real mess.
If your statement about recompilation for glibc2.2 is truth
(I suspect it is not yet 8)), it is not more harmful.


BTW, I have seen several days ago in a russian newsgroup
stormy discussion. The people argue that "Sparc 64bit userland"
simply does not exist. 8)8) Imagine, people using redhat, are _sure_,
that linux is not able to run 64bit applications, even not saying about
compilation and preparing 64bit binaries. 8)8)

Alexey

From owner-netdev@oss.sgi.com Mon Oct  2 10:08:01 2000
Received:  by oss.sgi.com id <S42442AbQJBRHv>;
	Mon, 2 Oct 2000 10:07:51 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:35089 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42440AbQJBRHU>;
	Mon, 2 Oct 2000 10:07:20 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA24331; Mon, 2 Oct 2000 21:06:22 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010021706.VAA24331@ms2.inr.ac.ru>
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
To:     ak@muc.de (Andi Kleen)
Date:   Mon, 2 Oct 2000 21:06:22 +0400 (MSK DST)
Cc:     andrewm@uow.EDU.AU, ak@muc.de, davem@redhat.com, netdev@oss.sgi.com
In-Reply-To: <20001001220124.33226@colin.muc.de> from "Andi Kleen" at Oct 1, 0 10:01:25 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 688       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> > However, I have to remind that open/close/ioctl __are__ serialized
> > with global semaphore.
> > 
> > To Andi: BKL is fully useless here, just because these calls are allowed
> > to sleep.
> 
> Of course it can sleep, in this case they have to lock themselves. With the
> BKL it would at least not be worse than in 2.2.

Did you read something but the last sentence? 8)8)

2.4 _did_ _not_ change anything here. BKL was equally useless in 2.2.


Andi, seems, it is time to remind that BKL in networking was
removed for several days. Think, why it was so easy.
[ Hint #1: softnet required much more time.
  Hint #2: network control paths are preemptable even in 2.2. ]

Alexey

From owner-netdev@oss.sgi.com Mon Oct  2 10:36:21 2000
Received:  by oss.sgi.com id <S42445AbQJBRgM>;
	Mon, 2 Oct 2000 10:36:12 -0700
Received: from laurin.munich.netsurf.de ([194.64.166.1]:39164 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S42440AbQJBRfq>; Mon, 2 Oct 2000 10:35:46 -0700
Received: from fred.muc.de (noidentity@ns1086.munich.netsurf.de [195.180.235.86])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id TAA02991;
	Mon, 2 Oct 2000 19:34:56 +0200 (MET DST)
Received: by fred.muc.de (Postfix, from userid 500)
	id 67749E3913; Mon,  2 Oct 2000 19:37:18 +0200 (CEST)
Date:   Mon, 2 Oct 2000 19:37:18 +0200
From:   Andi Kleen <ak@muc.de>
To:     kuznet@ms2.inr.ac.ru
Cc:     Andi Kleen <ak@muc.de>, andrewm@uow.EDU.AU, davem@redhat.com,
        netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
Message-ID: <20001002193718.A11667@fred.muc.de>
References: <20001001220124.33226@colin.muc.de> <200010021706.VAA24331@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200010021706.VAA24331@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Mon, Oct 02, 2000 at 07:11:44PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Oct 02, 2000 at 07:11:44PM +0200, A.N.Kuznetsov wrote:
> Hello!
> 
> > > However, I have to remind that open/close/ioctl __are__ serialized
> > > with global semaphore.
> > > 
> > > To Andi: BKL is fully useless here, just because these calls are allowed
> > > to sleep.
> > 
> > Of course it can sleep, in this case they have to lock themselves. With the
> > BKL it would at least not be worse than in 2.2.
> 
> Did you read something but the last sentence? 8)8)
> 
> 2.4 _did_ _not_ change anything here. BKL was equally useless in 2.2.

I guess we're talking about different things again. I was worrying
about the ioctls not being reentrant against themselves, not against the
RX/TX threads in interrupts. 

This is e.g. the case with PPP ioctls calling into the tty layer.



-Andi

-- 
This is like TV. I don't like TV.

From owner-netdev@oss.sgi.com Mon Oct  2 11:03:01 2000
Received:  by oss.sgi.com id <S42454AbQJBSCv>;
	Mon, 2 Oct 2000 11:02:51 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:62225 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42440AbQJBSCg>;
	Mon, 2 Oct 2000 11:02:36 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA24536; Mon, 2 Oct 2000 22:01:27 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010021801.WAA24536@ms2.inr.ac.ru>
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
To:     ak@muc.de (Andi Kleen)
Date:   Mon, 2 Oct 2000 22:01:27 +0400 (MSK DST)
Cc:     ak@muc.de, andrewm@uow.EDU.AU, davem@redhat.com, netdev@oss.sgi.com
In-Reply-To: <20001002193718.A11667@fred.muc.de> from "Andi Kleen" at Oct 2, 0 07:37:18 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 441       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> I guess we're talking about different things again. I was worrying
> about the ioctls not being reentrant against themselves, not against the
> RX/TX threads in interrupts. 

I mean the same.

> This is e.g. the case with PPP ioctls calling into the tty layer.

Nothing changed to worse side as well.

PPP does lots of SMP _locking_. This locking can be wrong, of course.
But BKL is apparently does not play there as well.

Alexey

From owner-netdev@oss.sgi.com Mon Oct  2 11:35:11 2000
Received:  by oss.sgi.com id <S42447AbQJBSfB>;
	Mon, 2 Oct 2000 11:35:01 -0700
Received: from mail.dialtoneinternet.net ([64.65.29.9]:5644 "HELO
        mailx.dialtoneinternet.net") by oss.sgi.com with SMTP
	id <S42446AbQJBSeh>; Mon, 2 Oct 2000 11:34:37 -0700
Received: (qmail 6756 invoked from network); 2 Oct 2000 18:33:56 -0000
Received: from proxy.dialtoneinternet.net (HELO kyle.local.dialtoneinternet.net) (216.87.223.254)
  by mail.dialtoneinternet.net with SMTP; 2 Oct 2000 18:33:56 -0000
Date:   Mon, 2 Oct 2000 14:33:56 -0400 (EDT)
From:   Kyle Sparger <ksparger@dialtoneinternet.net>
X-Sender: ksparger@vaevictis.local.dialtoneinternet.net
To:     netdev@oss.sgi.com
Subject: proxy arp handling with multiple NICs
Message-ID: <Pine.LNX.4.10.10010021359540.715-100000@vaevictis.local.dialtoneinternet.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi,

Found this email list in the maintainers file in 2.2.17, hopefully, it's
the right place to go.

I've been experiencing a problem with some of our multiple NIC servers, in
that all NICs reply when an arp request is sent to an IP on any one of the
NICs.  Here's a tcpdump log (addresses changed to protect the innocent) of
a request going to a 3 NIC system:

14:07:35.699706 B arp who-has xx.xx.xx.xxx tell 64.65.14.1
14:07:35.699905 P arp reply xx.xx.xx.xxx is-at 0:1:2:b:c1:9 (0:2:7e:a5:41:0)
14:07:35.700325 P arp reply xx.xx.xx.xxx is-at 0:50:da:46:eb:b9 (0:2:7e:a5:41:0)
14:07:35.700868 P arp reply xx.xx.xx.xxx is-at 0:1:2:5f:0:a4 (0:2:7e:a5:41:0)

Now, I understand that this has been an on-going with LVS as well, but I
propose that this is a problem for a reason different than that.  

Basically, what appears to be happening is that the sender picks one of
the MAC addresses.  That interface will receive the traffic, but send it
out the interface that has the IP address.  

If the interface receiving the traffic never sends traffic on it's own,
upstream switches never have the opportunity to learn a path to it, so
they continually flood the network.  This is a bad situation. :)

Now, as to my solution:  I propose that the behaviour being exibited is in
fact, a "proxy arp" (per RFC 1027), and that the arp_rcv code must NOT
send a reply unless one of the following two conditions is met:
	1.  The device sending the reply is the same device the
	requested IP address is installed on.
	2.  The device sending the reply has "proxy arp" enabled.

I attach a patch which seems to implement the change.  It is lightly
tested -- ie, it works for me -- and is against 2.2.17.  I have personally
seen the problem in 2.2.14 and 2.2.17, so I assume it exists in at least
14-17.  I did a quick review of 2.4.0-test8, and by my inexperienced eye,
it appears to suffer from the same problem.

Thanks,

Kyle Sparger - Senior System Administrator
Dialtone Internet - Extremely Fast Web Systems
(954) 581-0097 - Voice (954) 581-7629 - Fax
ksparger@dialtoneinternet.net
http://www.dialtoneinternet.net







From owner-netdev@oss.sgi.com Mon Oct  2 12:34:01 2000
Received:  by oss.sgi.com id <S42436AbQJBTdw>;
	Mon, 2 Oct 2000 12:33:52 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:22290 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42434AbQJBTdg>;
	Mon, 2 Oct 2000 12:33:36 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA25328; Mon, 2 Oct 2000 23:32:42 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010021932.XAA25328@ms2.inr.ac.ru>
Subject: Re: socklen_t instead of size_t in struct cmsghdr
To:     jakub@redhat.com
Date:   Mon, 2 Oct 2000 23:32:42 +0400 (MSK DST)
Cc:     davem@redhat.com, ak@muc.de, netdev@oss.sgi.com
In-Reply-To: <20001002120349.L9588@sunsite.ms.mff.cuni.cz> from "Jakub Jelinek" at Oct 2, 0 12:03:49 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 246       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Would it be possible to change

I apologize, I have just remembered one thing.

__ ALIGNMENT! __

cmsghdr is aligned differently on 64bit and 32bit architectures,
so that you have to do real convertor for ultra in any case. :-(

Alexey

From owner-netdev@oss.sgi.com Mon Oct  2 12:50:12 2000
Received:  by oss.sgi.com id <S42451AbQJBTuC>;
	Mon, 2 Oct 2000 12:50:02 -0700
Received: from sunsite.ms.mff.cuni.cz ([195.113.19.66]:13576 "EHLO
        sunsite.ms.mff.cuni.cz") by oss.sgi.com with ESMTP
	id <S42434AbQJBTtl>; Mon, 2 Oct 2000 12:49:41 -0700
Received: (from jj@localhost)
	by sunsite.ms.mff.cuni.cz (8.9.3/8.9.3) id VAA03115;
	Mon, 2 Oct 2000 21:52:22 +0200
Date:   Mon, 2 Oct 2000 21:52:22 +0200
From:   Jakub Jelinek <jakub@redhat.com>
To:     kuznet@ms2.inr.ac.ru
Cc:     davem@redhat.com, ak@muc.de, netdev@oss.sgi.com
Subject: Re: socklen_t instead of size_t in struct cmsghdr
Message-ID: <20001002215221.O9588@sunsite.ms.mff.cuni.cz>
Reply-To: Jakub Jelinek <jakub@redhat.com>
References: <20001002120349.L9588@sunsite.ms.mff.cuni.cz> <200010021638.UAA24172@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <200010021638.UAA24172@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Mon, Oct 02, 2000 at 08:38:57PM +0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Oct 02, 2000 at 08:38:57PM +0400, kuznet@ms2.inr.ac.ru wrote:
> Hello!
> 
> > Would it be possible to change
> 
> Shit! The same story is with all the struct msghdr.

msghdr is not that severe (at least from the 32<->64 bit translation point
of view, because it has to be translated anyways (it contains pointers)), so
in msghdr I'd think it would be worth just to change msg_controllen to int
(aka socklen_t, because kernel apparently has no socklen_t type), msg_iovlen
is completely unrelated and as it sits between 2 64bit pointers, using 64bit
value in between looks like a good idea. If I look at Solaris msghdr (the
only non-Linux system I can look at headers ATM), iovlen is int and
controllen is socklen_t.

> 
> > Sparc 64bit userland can definitely survive that change,
> 
> Then change it. Only together with msghdr. Types of msg_namelen,

namelen is already an int, so just controllen and cmsg_len remains.

> msg_controllen and cmsg_len must coincide and be socklen_t.
> Changing only cmsg_len you will create real mess.
> If your statement about recompilation for glibc2.2 is truth
> (I suspect it is not yet 8)), it is not more harmful.
> 
> BTW, I have seen several days ago in a russian newsgroup
> stormy discussion. The people argue that "Sparc 64bit userland"
> simply does not exist. 8)8) Imagine, people using redhat, are _sure_,
> that linux is not able to run 64bit applications, even not saying about
> compilation and preparing 64bit binaries. 8)8)

Well, Sparc 64bit userland exists for years, though especially because of
the massive ABI changes during the years (last major ABI changes because
Solaris cannot follow their own ABI has been done about a month ago) and
because of lack of time for it on my and DaveM's part it is not part of any
distributions yet (but it should change very soon).
But the compiler I use for all SPARC compilations is already 64bit ;) :

$ ldd `which gcc`
libc.so.6 => /lib64/libc.so.6 (0xfffff80000120000)
/lib64/ld-linux.so.2 => /lib64/ld-linux.so.2 (0xfffff80000000000)
$ gcc -v
Reading specs from /usr/lib/gcc-lib/sparc64-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)

	Jakub

From owner-netdev@oss.sgi.com Mon Oct  2 12:59:32 2000
Received:  by oss.sgi.com id <S42440AbQJBT7W>;
	Mon, 2 Oct 2000 12:59:22 -0700
Received: from sunsite.ms.mff.cuni.cz ([195.113.19.66]:46088 "EHLO
        sunsite.ms.mff.cuni.cz") by oss.sgi.com with ESMTP
	id <S42434AbQJBT7J>; Mon, 2 Oct 2000 12:59:09 -0700
Received: (from jj@localhost)
	by sunsite.ms.mff.cuni.cz (8.9.3/8.9.3) id WAA03192;
	Mon, 2 Oct 2000 22:01:55 +0200
Date:   Mon, 2 Oct 2000 22:01:55 +0200
From:   Jakub Jelinek <jakub@redhat.com>
To:     kuznet@ms2.inr.ac.ru
Cc:     jakub@redhat.com, davem@redhat.com, ak@muc.de, netdev@oss.sgi.com
Subject: Re: socklen_t instead of size_t in struct cmsghdr
Message-ID: <20001002220155.P9588@sunsite.ms.mff.cuni.cz>
Reply-To: Jakub Jelinek <jakub@redhat.com>
References: <20001002120349.L9588@sunsite.ms.mff.cuni.cz> <200010021932.XAA25328@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <200010021932.XAA25328@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Mon, Oct 02, 2000 at 11:32:42PM +0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Oct 02, 2000 at 11:32:42PM +0400, kuznet@ms2.inr.ac.ru wrote:
> Hello!
> 
> > Would it be possible to change
> 
> I apologize, I have just remembered one thing.
> 
> __ ALIGNMENT! __
> 
> cmsghdr is aligned differently on 64bit and 32bit architectures,
> so that you have to do real convertor for ultra in any case. :-(

Yes, but the different alignment is because of the 64bit type in struct
cmsghdr.
If you have struct { int a; int b; int c; } then it has the same sizeof and
alignment on 32bit and 64bit, and AFAIK all cmsg payloads don't need
32<->64bit translation (at least from DaveM's comments in the cmsg32
translation code, only SCM_RIGHTS and SCM_CREDENTIALS are done specially
there and one of those is array of int, the other is struct with 3 u32),
which means they have the same alignment as well.

	Jakub

From owner-netdev@oss.sgi.com Tue Oct  3 04:20:30 2000
Received:  by oss.sgi.com id <S42201AbQJCLUK>;
	Tue, 3 Oct 2000 04:20:10 -0700
Received: from atol.icm.edu.pl ([212.87.0.35]:34570 "EHLO atol.icm.edu.pl")
	by oss.sgi.com with ESMTP id <S42367AbQJCLTl>;
	Tue, 3 Oct 2000 04:19:41 -0700
Received: from burza.icm.edu.pl ([148.81.208.198]:13745 "EHLO burza.icm.edu.pl"
	ident: "IDENT-NONSENSE") by atol.icm.edu.pl with ESMTP
	id <S291551AbQJCLSv>; Tue, 3 Oct 2000 13:18:51 +0200
Received: (from rzm@localhost)
	by burza.icm.edu.pl (8.9.3/8.9.3/rzm-2.6/icm) id NAA11693
	for netdev@oss.sgi.com; Tue, 3 Oct 2000 13:18:46 +0200 (MET DST)
Date:	Tue, 3 Oct 2000 13:18:46 +0200
From:	Rafal Maszkowski <rzm@icm.edu.pl>
To:	netdev@oss.sgi.com
Subject: how many u32 filters?
Message-ID: <20001003131846.A10781@burza.icm.edu.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.1i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

I am adding u32 filters with commands like:
tc filter add dev eth0 parent 10:0 protocol ip prio 100 handle 800::2 u32 match ip dst 10.30.40.3 flowid 10:2
...

getting:
filter parent 10: protocol ip pref 100 u32
filter parent 10: protocol ip pref 100 u32 fh 800: ht divisor 1
filter parent 10: protocol ip pref 100 u32 fh 800::2 order 2 key ht 800 bkt 0 flowid 10:2
  match 0a1e2803/ffffffff at 16
filter parent 10: protocol ip pref 100 u32 fh 800::3 order 3 key ht 800 bkt 0 flowid 10:3
  match 0a1e2809/ffffffff at 16
...

and then I can delete them with
tc filter del  dev eth0 parent 10:0 protocol ip prio 100 handle 800::2 u32 match ip dst 10.30.40.3 flowid 10:2

It looks like the highest handle is 800::7ff (or maybe fff) and there may be
only 2048 filters with unique handles. They have to be unique to make single
filters deletetions possible.

Is it possible to setup the u32 filters in such a way that 64k or more unique
handles would be available?

I do not know if a single system would be able to carry such load but maybe it
is possible, I hope to be able to test it in the future. A company I work for
in principle may need tens of thousands of limits, putting every 2k of limits
on a separate machine would be limiting us to much.

R.
-- 
W iskier krzesaniu żywem/Materiał to rzecz główna

From owner-netdev@oss.sgi.com Tue Oct  3 06:22:40 2000
Received:  by oss.sgi.com id <S42329AbQJCNWU>;
	Tue, 3 Oct 2000 06:22:20 -0700
Received: from isis.its.uow.edu.au ([130.130.68.21]:49663 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42312AbQJCNVp>;
	Tue, 3 Oct 2000 06:21:45 -0700
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by isis.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id AAA26050;
	Wed, 4 Oct 2000 00:18:03 +1100 (EST)
Message-ID: <39D9DD06.66194B72@uow.edu.au>
Date:   Wed, 04 Oct 2000 00:20:06 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     kuznet@ms2.inr.ac.ru
CC:     netdev@oss.sgi.com
Subject: Re: [patch] tcp_tw in 2.4
References: <39D75F78.492E2CA5@uow.edu.au> from "Andrew Morton" at Oct 1, 0 08:15:01 pm <200010011645.UAA09976@ms2.inr.ac.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

kuznet@ms2.inr.ac.ru wrote:
> 
> Hello!
> 
> > * tcp_init() wants to set sysctl_tcp_max_tw_buckets to 180,000.  This
> > seems too high (Andi says 22 megs).  I think the patch here is more
> > consistent.
> 
> For machine with 256MB it is not very big number.
> 
> Failure to create tw bucket is hard bug. Default value is to be so high
> as possible.

So with 180k connections and a 60 second TCP_TIMEWAIT_LEN, the machine
is limited to a maximum sustained rate of 3,000 connections per second?

> > * tcp_twkill() can consume a huge amount of time if it has enough
> > connections to deal with.  When running lmbench I have observed it
> > killing 2,500 connections in a single pass, which means we spend 15
> > milliseconds in the timer handler.  This is crazy.
> 
> If you expect of machine doing 700 conn/sec superb latency,
> you expect an impossible thing.

OK, this isn't a very important issue for scheduling latency.  Can be
lived with.  But...

> We do much more particularly because the work is batched, when it is possible.
> 
> If you want to do sound recording on your web server,
> it is better to increase granularity of tw calendar.
> 
> > So I just kill a hundred and then reschedule the timer to run in a
> > couple of jiffies time.  The downside: this limits the tw reaping to
> > 2,500 connections per second.
> 
> You simply limited your power by 2500 conn/sec, not more.
> We must destroy buckets with the rate, which they are created.

Tell me if this is wrong:

A uniprocessor server is handling 3,000 connections per second (probably
not possible.  What is the maximum 2.4 can do?)

That server will reap the timed-wait connections once per 7.5 seconds.

So a single timer handler will kill 22,500 tcp_tw_buckets in a single
pass.

So that timer handler will not return for 0.14 seconds.

But the machine is under heavy interrupt load - the timer handler will
probably take 0.3 seconds or more.

So once per seven seconds:

 - the machine's backlog queue will fill up and it will drop
   around two thousand packets.  Subsequent client retransmits
   will add even more load.
 - No timer handlers or softirqs will run for 0.3 seconds.
 - Process accounting will stop.
 - Other scary things :)
 - The machine probably won't reach backlog equilibrium for
   half a second or more.

This all sounds pretty bad and suggests that either TCP_TWKILL_SLOTS is
far too small or I've missed something obvious :)

Increasing TCP_TWKILL_SLOTS to 256 would smooth things out, but I
suggest that something which is load-adaptive is more efficient and easy
to code.

From owner-netdev@oss.sgi.com Tue Oct  3 08:29:11 2000
Received:  by oss.sgi.com id <S42367AbQJCP3B>;
	Tue, 3 Oct 2000 08:29:01 -0700
Received: from ns.mls-inter.net ([204.244.222.1]:56336 "EHLO
        eddie.mls-inter.net") by oss.sgi.com with ESMTP id <S42299AbQJCP2q>;
	Tue, 3 Oct 2000 08:28:46 -0700
Received: from localhost (root@localhost)
	by eddie.mls-inter.net (8.11.0/8.9.3) with ESMTP id e93FSIQ27433;
	Tue, 3 Oct 2000 08:28:18 -0700
Date:   Tue, 3 Oct 2000 08:28:18 -0700 (PDT)
From:   Charles Howes <croot@micro-logistics.com>
To:     netdev@oss.sgi.com, linux-net@vger.rutgers.edu, davem@redhat.com,
        ak@muc.de, kuznet@ms2.inr.ac.ru
Subject: Proxy arp is broken: test program included
Message-ID: <Pine.LNX.4.21.0010030803120.24835-100000@eddie.mls-inter.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

I've found a bug in the proxy arp code that's in 2.2.x and
2.4.0-test8, probably the latest 2.4.0-testx-prex, and probably every
kernel (ok, I didn't test 2.0.x nor 1.2.x).

The problem: you can use the arp command to add and delete proxy arp
entries, but sometimes the arp command doesn't work.  In 2.2.15,
entries can't be deleted, and in 2.4.0 they can't be added.  Strace shows
that the 'arp' program is working, it's the kernel that's at fault.

I was attempting to make a transparent firewall using proxy arp at the
time this bug was discovered.  Major egg on face when it worked in
testing but not in production.

I've included a short test program that shows the problem.

-----------------------8<---cut here---8<--------------
#!/bin/sh
# Arp bug tester by Charles Howes -- chowes@mls-inter.net
# 2000-10-03 08:24:13

CLASSC=10.0.2
IP1=$CLASSC.1
IP2=$CLASSC.2
# If you make PUB="", it works, but that's not what we're testing.
#PUB=
PUB=pub

# Set up an ip address so that you can set up proxy arp entries:
ifconfig eth0:1 $IP1
# Add one:
arp -Ds $IP2 eth0 $PUB
# Delete one:
arp -d $IP2 $PUB
# These arps add and then delete an entry.  They may work correctly
#the first time, that's why the results are ignored here.
#There should be nothing in the arp table about $IP2, right?

A=`arp -n | md5sum -`
   arp -Ds $IP2 eth0 $PUB
B=`arp -n | md5sum -`
   arp -d $IP2 $PUB
C=`arp -n | md5sum -`

# If the add and delete commands worked right, A=C and A!=B
# If unrelated arp entries show up in the arp table, this test will be
# disrupted; but really, new arp entries are rare enough that this
# shouldn't be a problem.  If it is a problem, unplug your ethernet card 
# and/or stop running portscans of your local subnet during this test.
if [ "$A" = "$C" -a "$A" != "$B" ]; then
  echo "That worked right!"
  exit 0
fi

# Ok, it didn't work right; in what way did it fail?
# When a pub arp entry is deleted, it shows up as 'incomplete' for a while
if arp -n | fgrep "$IP2 " | grep -qiv incomplete; then
  echo "I found $IP2 in your arp table after trying to delete it."
else
  echo "I didn't find $IP2 in your arp table after trying to add it."
fi
exit 2
-----------------------8<---cut here---8<--------------

--
Charles Howes -- chowes@micro-logistics.com


From owner-netdev@oss.sgi.com Tue Oct  3 10:15:00 2000
Received:  by oss.sgi.com id <S42464AbQJCROk>;
	Tue, 3 Oct 2000 10:14:40 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:5130 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42299AbQJCROD>;
	Tue, 3 Oct 2000 10:14:03 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA05684; Tue, 3 Oct 2000 21:13:02 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010031713.VAA05684@ms2.inr.ac.ru>
Subject: Re: [patch] tcp_tw in 2.4
To:     andrewm@uow.edu.au (Andrew Morton)
Date:   Tue, 3 Oct 2000 21:13:02 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <39D9DD06.66194B72@uow.edu.au> from "Andrew Morton" at Oct 4, 0 00:20:06 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 1185      
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> So with 180k connections and a 60 second TCP_TIMEWAIT_LEN, the machine
> is limited to a maximum sustained rate of 3,000 connections per second?

Yes. From ip-sysctl.h:

tcp_max_tw_buckets - INTEGER
	Maximal number of timewait sockets held by system simultaneously.
	If this number is exceeded time-wait socket is immediately destroyed
	and warning is printed. This limit exists only to prevent
	simple DoS attacks, you _must_ not lower the limit artificially,
	but rather increase it (probably, after increasing installed memory),
	if network conditions require more than default value.


> A uniprocessor server is handling 3,000 connections per second (probably
> not possible.  What is the maximum 2.4 can do?)

I see ~5000 on pretty bad hardware. I have no idea how much
of cps high end machines can make.


> This all sounds pretty bad and suggests that either TCP_TWKILL_SLOTS is
> far too small or I've missed something obvious :)

Yes, it is too small, no doubts.

Unfortunately, this problem was hidden, because I used tcp_tw_recycle
in all the testing and the problem did not exist with this option.

As soon as it is disabled, this code must be reworked.

Alexey

From owner-netdev@oss.sgi.com Tue Oct  3 11:24:51 2000
Received:  by oss.sgi.com id <S42479AbQJCSYl>;
	Tue, 3 Oct 2000 11:24:41 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:18954 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42249AbQJCSYX>;
	Tue, 3 Oct 2000 11:24:23 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA06019; Tue, 3 Oct 2000 22:23:26 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010031823.WAA06019@ms2.inr.ac.ru>
Subject: Re: socklen_t instead of size_t in struct cmsghdr
To:     jakub@redhat.com
Date:   Tue, 3 Oct 2000 22:23:26 +0400 (MSK DST)
Cc:     davem@redhat.com, ak@muc.de, netdev@oss.sgi.com
In-Reply-To: <20001002220155.P9588@sunsite.ms.mff.cuni.cz> from "Jakub Jelinek" at Oct 2, 0 10:01:55 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 525       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Yes, but the different alignment is because of the 64bit type in struct
> cmsghdr.

No! That's problem. Alignment of cmsgs is forced to unsigned long.
Look at macros CMSG_*

cmsgs may contain qword aligned objects (which also require translation,
by the way). It is problem.

F.e. I forced 32bit alignment in rtnetlink to help you and Dave.
But thing, which is allowed there, can be not allowed with cmsgs.
At least bad alignment smells like you are going to emulate
64bit interface on top of 32bit one. 8)

Alexey

From owner-netdev@oss.sgi.com Tue Oct  3 11:28:11 2000
Received:  by oss.sgi.com id <S42299AbQJCS2B>;
	Tue, 3 Oct 2000 11:28:01 -0700
Received: from devserv.devel.redhat.com ([207.175.42.156]:31755 "EHLO
        devserv.devel.redhat.com") by oss.sgi.com with ESMTP
	id <S42274AbQJCS1r>; Tue, 3 Oct 2000 11:27:47 -0700
Received: (from jakub@localhost)
	by devserv.devel.redhat.com (8.11.0/8.11.0) id e93IQGp20892;
	Tue, 3 Oct 2000 14:26:16 -0400
Date:   Tue, 3 Oct 2000 14:26:15 -0400
From:   Jakub Jelinek <jakub@redhat.com>
To:     kuznet@ms2.inr.ac.ru
Cc:     davem@redhat.com, ak@muc.de, netdev@oss.sgi.com
Subject: Re: socklen_t instead of size_t in struct cmsghdr
Message-ID: <20001003142615.J30053@devserv.devel.redhat.com>
Reply-To: Jakub Jelinek <jakub@redhat.com>
References: <20001002220155.P9588@sunsite.ms.mff.cuni.cz> <200010031823.WAA06019@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200010031823.WAA06019@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Tue, Oct 03, 2000 at 10:23:26PM +0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, Oct 03, 2000 at 10:23:26PM +0400, kuznet@ms2.inr.ac.ru wrote:
> Hello!
> 
> > Yes, but the different alignment is because of the 64bit type in struct
> > cmsghdr.
> 
> No! That's problem. Alignment of cmsgs is forced to unsigned long.
> Look at macros CMSG_*
> 
> cmsgs may contain qword aligned objects (which also require translation,
> by the way). It is problem.
> 
> F.e. I forced 32bit alignment in rtnetlink to help you and Dave.
> But thing, which is allowed there, can be not allowed with cmsgs.
> At least bad alignment smells like you are going to emulate
> 64bit interface on top of 32bit one. 8)

Let's wait for DaveM then, worst case I'll hack some %sp munging so that the
cmsg fixup is not done in situ.

	Jakub

From owner-netdev@oss.sgi.com Wed Oct  4 01:47:47 2000
Received:  by oss.sgi.com id <S42497AbQJDIr1>;
	Wed, 4 Oct 2000 01:47:27 -0700
Received: from pizda.ninka.net ([216.101.162.242]:34717 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42267AbQJDIrA>;
	Wed, 4 Oct 2000 01:47:00 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id BAA15818;
	Wed, 4 Oct 2000 01:31:17 -0700
Date:   Wed, 4 Oct 2000 01:31:17 -0700
Message-Id: <200010040831.BAA15818@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     jakub@redhat.com
CC:     kuznet@ms2.inr.ac.ru, jakub@redhat.com, ak@muc.de,
        netdev@oss.sgi.com
In-reply-to: <20001002220155.P9588@sunsite.ms.mff.cuni.cz> (message from Jakub
	Jelinek on Mon, 2 Oct 2000 22:01:55 +0200)
Subject: Re: socklen_t instead of size_t in struct cmsghdr
References: <20001002120349.L9588@sunsite.ms.mff.cuni.cz> <200010021932.XAA25328@ms2.inr.ac.ru> <20001002220155.P9588@sunsite.ms.mff.cuni.cz>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: Mon, 2 Oct 2000 22:01:55 +0200
   From: Jakub Jelinek <jakub@redhat.com>

   On Mon, Oct 02, 2000 at 11:32:42PM +0400, kuznet@ms2.inr.ac.ru wrote:
   > cmsghdr is aligned differently on 64bit and 32bit architectures,
   > so that you have to do real convertor for ultra in any case. :-(

   Yes, but the different alignment is because of the 64bit type in struct
   cmsghdr.

Not completely, this alignment also comes from CMSG opaque data area
contents of which none of us have any control.  See?  It must end up
being 64-bit aligned and with a length which is modulo 64-bits.

Alexey is right, and I don't think this suggested fix will work.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Wed Oct  4 22:26:36 2000
Received:  by oss.sgi.com id <S42406AbQJEF00>;
	Wed, 4 Oct 2000 22:26:26 -0700
Received: from mail.inconnect.com ([209.140.64.7]:10951 "HELO
        mail.inconnect.com") by oss.sgi.com with SMTP id <S42379AbQJEFZq>;
	Wed, 4 Oct 2000 22:25:46 -0700
Received: (qmail 23106 invoked from network); 5 Oct 2000 05:25:04 -0000
Received: from ultra1.inconnect.com (209.140.64.2)
  by mail with SMTP; 5 Oct 2000 05:25:04 -0000
Date:   Wed, 4 Oct 2000 23:25:04 -0600 (MDT)
From:   Keyshaun <thekernel@subdimension.com>
X-Sender: kruger@ultra1.inconnect.com
To:     Linux Netdev <netdev@oss.sgi.com>
Subject: Coding style changes
Message-ID: <Pine.SOL.4.21.0010042320570.24906-100000@ultra1.inconnect.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi, I recently bought Linux Device Drivers.  It is very helpful, though I
still need to know how to write good 2.4 ready drivers.  The latest stable
kernel was only 2.0.30 when the book was written and if I recall alot has
changed since then.  If there is a summary of coding style changes and
conventions especially concerning modularization I would be interested in
making my code work properly in a native 2.4 environment.

Shaun Kruger


From owner-netdev@oss.sgi.com Thu Oct  5 13:50:21 2000
Received:  by oss.sgi.com id <S42324AbQJEUuL>;
	Thu, 5 Oct 2000 13:50:11 -0700
Received: from [209.140.64.7] ([209.140.64.7]:51587 "HELO mail.inconnect.com")
	by oss.sgi.com with SMTP id <S42310AbQJEUtk>;
	Thu, 5 Oct 2000 13:49:40 -0700
Received: (qmail 16676 invoked from network); 5 Oct 2000 20:48:03 -0000
Received: from ultra1.inconnect.com (209.140.64.2)
  by mail with SMTP; 5 Oct 2000 20:48:03 -0000
Date:   Thu, 5 Oct 2000 14:48:03 -0600 (MDT)
From:   Keyshaun <thekernel@subdimension.com>
X-Sender: kruger@ultra1.inconnect.com
To:     Linux Netdev <netdev@oss.sgi.com>
Subject: Windows driver reverse engineer
Message-ID: <Pine.SOL.4.21.0010051444220.16641-100000@ultra1.inconnect.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi, I am trying to get development info from a company funded by Microsoft
so I can support their network interface under Linux.  I will feel lucky
if I can get a PCI register and command listing.  I need to know how to
use the Windows debugging info to crack it.  I heard that some other
driver writers have resorted to this.  If anyone knows how to do this
please help me and tell me where to get the info for it.

Shaun Kruger
thekernel@subdimension.com


From owner-netdev@oss.sgi.com Thu Oct  5 14:16:41 2000
Received:  by oss.sgi.com id <S42367AbQJEVQc>;
	Thu, 5 Oct 2000 14:16:32 -0700
Received: from host000012.arnet.net.ar ([200.45.0.12]:775 "HELO
        smtp1.arnet.com.ar") by oss.sgi.com with SMTP id <S42353AbQJEVP5>;
	Thu, 5 Oct 2000 14:15:57 -0700
Received: (qmail 29765 invoked by uid 0); 5 Oct 2000 22:11:39 -0000
Received: from recife.arnet.com.ar ([200.45.0.70]) by mail1.arnet.com.ar  with Microsoft SMTPSVC(5.5.1877.357.35);
	 Mon, 2 Oct 2000 14:54:20 -0300
Received: (qmail 18969 invoked from network); 2 Oct 2000 17:47:35 -0000
Received: from oss.sgi.com (216.32.174.190)
  by recife.arnet.com.ar with SMTP; 2 Oct 2000 17:47:35 -0000
Received:  by oss.sgi.com id <S42445AbQJBRgM>;
	Mon, 2 Oct 2000 10:36:12 -0700
Received: from laurin.munich.netsurf.de ([194.64.166.1]:39164 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S42440AbQJBRfq>; Mon, 2 Oct 2000 10:35:46 -0700
Received: from fred.muc.de (noidentity@ns1086.munich.netsurf.de [195.180.235.86])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id TAA02991;
	Mon, 2 Oct 2000 19:34:56 +0200 (MET DST)
Received: by fred.muc.de (Postfix, from userid 500)
	id 67749E3913; Mon,  2 Oct 2000 19:37:18 +0200 (CEST)
Date:   Mon, 2 Oct 2000 19:37:18 +0200
From:   Andi Kleen <ak@muc.de>
To:     kuznet@ms2.inr.ac.ru
Cc:     Andi Kleen <ak@muc.de>, andrewm@uow.EDU.AU, davem@redhat.com,
        netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
Message-ID: <20001002193718.A11667@fred.muc.de>
References: <20001001220124.33226@colin.muc.de> <200010021706.VAA24331@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200010021706.VAA24331@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Mon, Oct 02, 2000 at 07:11:44PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


On Mon, Oct 02, 2000 at 07:11:44PM +0200, A.N.Kuznetsov wrote:
> Hello!
> 
> > > However, I have to remind that open/close/ioctl __are__ serialized
> > > with global semaphore.
> > > 
> > > To Andi: BKL is fully useless here, just because these calls are allowed
> > > to sleep.
> > 
> > Of course it can sleep, in this case they have to lock themselves. With the
> > BKL it would at least not be worse than in 2.2.
> 
> Did you read something but the last sentence? 8)8)
> 
> 2.4 _did_ _not_ change anything here. BKL was equally useless in 2.2.

I guess we're talking about different things again. I was worrying
about the ioctls not being reentrant against themselves, not against the
RX/TX threads in interrupts. 

This is e.g. the case with PPP ioctls calling into the tty layer.



-Andi

-- 
This is like TV. I don't like TV.

From owner-netdev@oss.sgi.com Fri Oct  6 00:40:15 2000
Received:  by oss.sgi.com id <S42516AbQJFHjz>;
	Fri, 6 Oct 2000 00:39:55 -0700
Received: from pizda.ninka.net ([216.101.162.242]:15245 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42515AbQJFHjj>;
	Fri, 6 Oct 2000 00:39:39 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id VAA05218;
	Thu, 5 Oct 2000 21:17:10 -0700
Date:   Thu, 5 Oct 2000 21:17:10 -0700
Message-Id: <200010060417.VAA05218@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     hadi@cyberus.ca
CC:     kuznet@ms2.inr.ac.ru, Robert.Olsson@data.slu.se,
        linux-kernel@vger.kernel.org, eis@baty.hanse.de,
        netdev@oss.sgi.com, becker@scyld.com
In-reply-to: <Pine.GSO.4.20.0009252212460.18941-200000@shell.cyberus.ca>
	(message from jamal on Mon, 25 Sep 2000 22:20:36 -0400 (EDT))
Subject: Re: [PATCH: Final ] WAS (Re: [PATCH/RFC] (long) network interface changes
References:  <Pine.GSO.4.20.0009252212460.18941-200000@shell.cyberus.ca>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: Mon, 25 Sep 2000 22:20:36 -0400 (EDT)
   From: jamal <hadi@cyberus.ca>

   Final patch with feedback from Henner to change the naming
   convention of the return codes. Clean it up, polish it, junk it
   etc.

Jamal, I have no problems with these changes I think.

Could you resend me a clean complete diff against test9 final?  Thank
you.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Fri Oct  6 03:06:25 2000
Received:  by oss.sgi.com id <S42527AbQJFKGP>;
	Fri, 6 Oct 2000 03:06:15 -0700
Received: from [192.72.45.189] ([192.72.45.189]:62184 "EHLO
        stsl.siemens.com.tw") by oss.sgi.com with ESMTP id <S42526AbQJFKFw>;
	Fri, 6 Oct 2000 03:05:52 -0700
Received: from stslex.siemens.com.tw (stslex [192.72.45.13])
	by stsl.siemens.com.tw (8.9.1/8.9.1) with ESMTP id SAA16840
	for <netdev@oss.sgi.com>; Fri, 6 Oct 2000 18:13:25 +0800 (CST)
Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2448.0)
	id <4CJ50ZP1>; Fri, 6 Oct 2000 17:55:03 +0800
Message-ID: <C6BEA88DAF6AD31185F500105A835CBB01BAC139@stslex.siemens.com.tw>
From:   Moter Du <Moter_Du@stsl.siemens.com.tw>
To:     netdev@oss.sgi.com
Subject: linux-2.2.17 auto-configuration
Date:   Fri, 6 Oct 2000 17:55:01 +0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C02F7B.7E8F74AC"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C02F7B.7E8F74AC
Content-Type: text/plain;
	charset="BIG5"

I'm confused by auto-configuration in linux-2.2.17. In summary it seems
Linux supports only solicited auto-configuration, not unsolicited
auto-configuration. The term 'solicited auto-configuration' means Linux
sends a RS and Router replies a RA. The term 'unsolicited
auto-configuration' means Router advertises a RA periodically. In the latter
case Linux does receive the RA, but it never auto-configured itself.

I should trace into the kernel. But if some can point out the answer I would
appreciate very much.

> 	Sincerely 
> 	Moter Du
> 
> 	============================================================
> 	Moter Du                                  D410, Siemens STSL
> 	phone	+886 2 25186011
> 	Fax	+886 2 25053866
> 	mailto:moter_du@stsl.siemens.com.tw
		============================================================



------_=_NextPart_001_01C02F7B.7E8F74AC
Content-Type: text/html;
	charset="BIG5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DBIG5">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>linux-2.2.17 auto-configuration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Courier New">I'm confused by =
auto-configuration in linux-2.2.17. In summary it seems Linux supports =
only solicited auto-configuration, not unsolicited auto-configuration. =
The term 'solicited auto-configuration' means Linux sends a RS and =
Router replies a RA. The term 'unsolicited auto-configuration' means =
Router advertises a RA periodically. In the latter case Linux does =
receive the RA, but it never auto-configured itself.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">I should trace into the kernel. =
But if some can point out the answer I would appreciate very =
much.</FONT>
</P>
<UL><UL>
<P><FONT COLOR=3D"#000000" FACE=3D"Courier New">Sincerely </FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Courier New">Moter Du</FONT>
</P>

<P><FONT COLOR=3D"#000000" FACE=3D"Courier =
New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Courier New">Moter =
Du&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; D410, Siemens =
STSL</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Courier New">phone&nbsp;&nbsp; +886 =
2 25186011</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Courier =
New">Fax&nbsp;&nbsp;&nbsp;&nbsp; +886 2 25053866</FONT>
<BR><U><FONT COLOR=3D"#0000FF" FACE=3D"Courier New"><A =
HREF=3D"mailto:moter_du@stsl.siemens.com.tw">mailto:moter_du@stsl.siemen=
s.com.tw</A></FONT></U>
<BR><FONT FACE=3D"Courier =
New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
</P>
<BR>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01C02F7B.7E8F74AC--

From owner-netdev@oss.sgi.com Fri Oct  6 07:07:38 2000
Received:  by oss.sgi.com id <S42251AbQJFOHS>;
	Fri, 6 Oct 2000 07:07:18 -0700
Received: from mars.iol.unh.edu ([132.177.121.222]:27240 "EHLO iol.unh.edu")
	by oss.sgi.com with ESMTP id <S42201AbQJFOGy>;
	Fri, 6 Oct 2000 07:06:54 -0700
Received: from localhost (jfl@localhost)
	by iol.unh.edu (8.9.3/8.9.3) with ESMTP id KAA16614;
	Fri, 6 Oct 2000 10:08:07 -0400 (EDT)
Date:   Fri, 6 Oct 2000 10:08:07 -0400
From:   "John F. Leser" <jfl@iol.unh.edu>
To:     Moter Du <Moter_Du@stsl.siemens.com.tw>
cc:     netdev@oss.sgi.com
Subject: Re: linux-2.2.17 auto-configuration
In-Reply-To: <C6BEA88DAF6AD31185F500105A835CBB01BAC139@stslex.siemens.com.tw>
Message-ID: <Pine.SGI.4.20.0010061003290.16528-100000@mars.iol.unh.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


I'm using linux-2.2.17 and it seems to have no trouble doing address
autoconfiguration from unsolicited router advertisements.  I found that
the token used to form the global address is the EUI-64, not the old style
token without the 'ff:fe' in the middle - if you're trying to ping the
address to verify that autoconfiguration took place, this could lead to
confusion. 


On Fri, 6 Oct 2000, Moter Du wrote:

> I'm confused by auto-configuration in linux-2.2.17. In summary it seems
> Linux supports only solicited auto-configuration, not unsolicited
> auto-configuration. The term 'solicited auto-configuration' means Linux
> sends a RS and Router replies a RA. The term 'unsolicited
> auto-configuration' means Router advertises a RA periodically. In the latter
> case Linux does receive the RA, but it never auto-configured itself.
> 
> I should trace into the kernel. But if some can point out the answer I would
> appreciate very much.
> 
> > 	Sincerely 
> > 	Moter Du
> > 
> > 	============================================================
> > 	Moter Du                                  D410, Siemens STSL
> > 	phone	+886 2 25186011
> > 	Fax	+886 2 25053866
> > 	mailto:moter_du@stsl.siemens.com.tw
> 		============================================================
> 
> 
> 


------------------------------------------------------------------- 
John Leser 			UNH InterOperability Lab 
IP/Routing Consortium Engineer 	Morse Hall, 39 College Rd, Room 332
Tel: (603) 862-0090 (8-5 EST) 	Durham, NH 03824-3525 
Fax: (603) 862-1761		Web: www.iol.unh.edu
-------------------------------------------------------------------


From owner-netdev@oss.sgi.com Fri Oct  6 15:26:21 2000
Received:  by oss.sgi.com id <S42379AbQJFW0B>;
	Fri, 6 Oct 2000 15:26:01 -0700
Received: from brutus.conectiva.com.br ([200.250.58.146]:28411 "EHLO
        brutus.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S42342AbQJFWZ4>; Fri, 6 Oct 2000 15:25:56 -0700
Received: from localhost (riel@localhost)
	by brutus.conectiva.com.br (8.10.2/8.10.2) with ESMTP id e96MPcu18312;
	Fri, 6 Oct 2000 19:25:38 -0300
X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs
Date:   Fri, 6 Oct 2000 19:25:38 -0300 (BRST)
From:   Rik van Riel <riel@conectiva.com.br>
X-Sender: riel@duckman.distro.conectiva
To:     netdev <netdev@oss.sgi.com>
cc:     linux-kernel@vger.redhat.com
Subject: BUG in tcp.c ?
Message-ID: <Pine.LNX.4.21.0010061917420.13585-100000@duckman.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi,

I found the following lines in tcp.c, after trying to identify
and track down what I thought to be an nbd bug...

net/ipv4/tcp.c:

   1028       if (tcp_memory_free(sk))
   1029               skb = tcp_alloc_skb(sk, tmp, GFP_KERNEL)

While this looks ok at first glance, it rather conflicts with
the following lines of code from net/core/sock.c:

    785               skb = alloc_skb(try_size, sk->allocation);

And from drivers/block/nbd.c:

    109               sock->sk->allocation = GFP_ATOMIC;
......
    121               if (send)
    122                       result = sock_sendmsg(sock, &msg, size);


Here we see that the nbd driver sets the allocation type to
GFP_ATOMIC (and for a good reason), sock.c honours this field,
but for some reason tcp.c doesn't ...

Is this an actual bug, or am I overlooking something?

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/


From owner-netdev@oss.sgi.com Fri Oct  6 15:30:51 2000
Received:  by oss.sgi.com id <S42215AbQJFWab>;
	Fri, 6 Oct 2000 15:30:31 -0700
Received: from pizda.ninka.net ([216.101.162.242]:6806 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42210AbQJFWaR>;
	Fri, 6 Oct 2000 15:30:17 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id PAA03502;
	Fri, 6 Oct 2000 15:16:33 -0700
Date:   Fri, 6 Oct 2000 15:16:33 -0700
Message-Id: <200010062216.PAA03502@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     riel@conectiva.com.br
CC:     netdev@oss.sgi.com, linux-kernel@vger.redhat.com
In-reply-to: 
	<Pine.LNX.4.21.0010061917420.13585-100000@duckman.distro.conectiva>
	(message from Rik van Riel on Fri, 6 Oct 2000 19:25:38 -0300 (BRST))
Subject: Re: BUG in tcp.c ?
References:  <Pine.LNX.4.21.0010061917420.13585-100000@duckman.distro.conectiva>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date:   Fri, 6 Oct 2000 19:25:38 -0300 (BRST)
   From: Rik van Riel <riel@conectiva.com.br>

   Is this an actual bug, or am I overlooking something?

It is a bug and I'll change TCP's sendmsg to use sk->allocation as it
should.  Thanks for pointing this out.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Fri Oct  6 15:41:11 2000
Received:  by oss.sgi.com id <S42222AbQJFWlB>;
	Fri, 6 Oct 2000 15:41:01 -0700
Received: from perninha.conectiva.com.br ([200.250.58.156]:12817 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S42210AbQJFWkt>; Fri, 6 Oct 2000 15:40:49 -0700
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id TAA15676;
	Fri, 6 Oct 2000 19:39:28 -0300
Date:   Fri, 6 Oct 2000 17:45:47 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     "David S. Miller" <davem@redhat.com>
cc:     riel@conectiva.com.br, netdev@oss.sgi.com,
        linux-kernel@vger.kernel.org
Subject: Re: BUG in tcp.c ?
In-Reply-To: <200010062216.PAA03502@pizda.ninka.net>
Message-ID: <Pine.LNX.4.21.0010061741170.9575-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


On Fri, 6 Oct 2000, David S. Miller wrote:

>    Date:   Fri, 6 Oct 2000 19:25:38 -0300 (BRST)
>    From: Rik van Riel <riel@conectiva.com.br>
> 
>    Is this an actual bug, or am I overlooking something?
> 
> It is a bug and I'll change TCP's sendmsg to use sk->allocation as it
> should.  Thanks for pointing this out.
 

2.2.17 is broken too. 


From owner-netdev@oss.sgi.com Fri Oct  6 16:15:41 2000
Received:  by oss.sgi.com id <S42255AbQJFXPb>;
	Fri, 6 Oct 2000 16:15:31 -0700
Received: from pizda.ninka.net ([216.101.162.242]:26006 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42210AbQJFXP0>;
	Fri, 6 Oct 2000 16:15:26 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id QAA06320;
	Fri, 6 Oct 2000 16:01:45 -0700
Date:   Fri, 6 Oct 2000 16:01:45 -0700
Message-Id: <200010062301.QAA06320@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     marcelo@conectiva.com.br
CC:     riel@conectiva.com.br, netdev@oss.sgi.com,
        linux-kernel@vger.kernel.org
In-reply-to: <Pine.LNX.4.21.0010061741170.9575-100000@freak.distro.conectiva>
	(message from Marcelo Tosatti on Fri, 6 Oct 2000 17:45:47 -0200
	(BRST))
Subject: Re: BUG in tcp.c ?
References:  <Pine.LNX.4.21.0010061741170.9575-100000@freak.distro.conectiva>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date:   Fri, 6 Oct 2000 17:45:47 -0200 (BRST)
   From: Marcelo Tosatti <marcelo@conectiva.com.br>

   2.2.17 is broken too. 

I've fixed it in my 2.2.x sources as well.
Thanks.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Sat Oct  7 07:15:09 2000
Received:  by oss.sgi.com id <S42182AbQJGOPA>;
	Sat, 7 Oct 2000 07:15:00 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:40455 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42173AbQJGOOi>;
	Sat, 7 Oct 2000 07:14:38 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id SAA30580; Sat, 7 Oct 2000 18:14:27 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010071414.SAA30580@ms2.inr.ac.ru>
Subject: Re: BUG in tcp.c ?
To:     davem@redhat.COM (David S. Miller)
Date:   Sat, 7 Oct 2000 18:14:26 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <200010062301.QAA06320@pizda.ninka.net> from "David S. Miller" at Oct 7, 0 03:45:00 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 302       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

>    2.2.17 is broken too. 
> 
> I've fixed it in my 2.2.x sources as well.

Dave, sendmsg cannot be used from interrupt yet.
Even in 2.2 it works sometimes, but surely will crash sometimes (f.e.
because of socket lock on interrupt).

If some caller needs this, I am sure, it is buggy.

Alexey

From owner-netdev@oss.sgi.com Sat Oct  7 07:58:29 2000
Received:  by oss.sgi.com id <S42183AbQJGO6T>;
	Sat, 7 Oct 2000 07:58:19 -0700
Received: from laurin.munich.netsurf.de ([194.64.166.1]:14744 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S42173AbQJGO6D>; Sat, 7 Oct 2000 07:58:03 -0700
Received: from fred.muc.de (noidentity@ns1083.munich.netsurf.de [195.180.235.83])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id QAA17349;
	Sat, 7 Oct 2000 16:57:51 +0200 (MET DST)
Received: by fred.muc.de (Postfix, from userid 500)
	id 5932BE3912; Sat,  7 Oct 2000 17:01:47 +0200 (CEST)
Date:   Sat, 7 Oct 2000 17:01:47 +0200
From:   Andi Kleen <ak@muc.de>
To:     kuznet@ms2.inr.ac.ru
Cc:     "David S. Miller" <davem@redhat.COM>, netdev@oss.sgi.com
Subject: Re: BUG in tcp.c ?
Message-ID: <20001007170147.A1657@fred.muc.de>
References: <200010062301.QAA06320@pizda.ninka.net> <200010071414.SAA30580@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200010071414.SAA30580@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Sat, Oct 07, 2000 at 04:16:09PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sat, Oct 07, 2000 at 04:16:09PM +0200, A.N.Kuznetsov wrote:
> Hello!
> 
> >    2.2.17 is broken too. 
> > 
> > I've fixed it in my 2.2.x sources as well.
> 
> Dave, sendmsg cannot be used from interrupt yet.
> Even in 2.2 it works sometimes, but surely will crash sometimes (f.e.
> because of socket lock on interrupt).
> 
> If some caller needs this, I am sure, it is buggy.

iirc nbd doesn't need it from an interrupt but just to avoid deadlock
on low memory situations when you swap over it.

Of course it is still broken because there are enough other problems
with swapping over TCP :-)


-Andi
-- 
This is like TV. I don't like TV.

From owner-netdev@oss.sgi.com Sat Oct  7 08:49:39 2000
Received:  by oss.sgi.com id <S42185AbQJGPt3>;
	Sat, 7 Oct 2000 08:49:29 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:17676 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42173AbQJGPtO>;
	Sat, 7 Oct 2000 08:49:14 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA31074; Sat, 7 Oct 2000 19:49:01 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010071549.TAA31074@ms2.inr.ac.ru>
Subject: Re: BUG in tcp.c ?
To:     ak@muc.de (Andi Kleen)
Date:   Sat, 7 Oct 2000 19:49:01 +0400 (MSK DST)
Cc:     davem@redhat.COM, netdev@oss.sgi.com
In-Reply-To: <20001007170147.A1657@fred.muc.de> from "Andi Kleen" at Oct 7, 0 05:01:47 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 685       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> iirc nbd doesn't need it from an interrupt but just to avoid deadlock
> on low memory situations when you swap over it.

Hmm... seems, I do not understand. Are such deadlocks prevented
by some special GFP values without any inheriting? This sounds strange.
It is evident candidate to an attribute in task struct, at least.
This was something sort of PF_MEMALLOC, if I remember correclty.


BTW we had problem with kmalloc (that which was fixed by your patch)
exactly because it avoids deadlocks and does not respect reliability
of GFP_KERNEL. So, does it mean that we have not only unreliable
GFP_KERNEL but also inclined to deadlocks in any case? Fuuunny situation.

Alexey

From owner-netdev@oss.sgi.com Sat Oct  7 08:52:49 2000
Received:  by oss.sgi.com id <S42186AbQJGPwj>;
	Sat, 7 Oct 2000 08:52:39 -0700
Received: from mail.bieringer.de ([195.226.187.51]:26116 "HELO
        titan.bieringer.de") by oss.sgi.com with SMTP id <S42173AbQJGPwb>;
	Sat, 7 Oct 2000 08:52:31 -0700
Received: (qmail 12249 invoked from network); 7 Oct 2000 15:52:28 -0000
Received: from p3e991650.dip.t-dialin.net (HELO worker.bieringer.de) (62.153.22.80)
  by mail.bieringer.de with SMTP; 7 Oct 2000 15:52:28 -0000
Message-Id: <5.0.0.25.0.20001007174404.02a80890@mail.bieringer.de>
X-Sender: peter@mail.bieringer.de
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date:   Sat, 07 Oct 2000 17:54:40 +0200
To:     netdev@oss.sgi.com
From:   Peter Bieringer <pb@bieringer.de>
Subject: Filtering outgoing tunneled IPv6 packets with ipchains -
  possible?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi,

I got an interesting problem. On my IPv6 tunnel server, I do some simple 
IPv4 accounting using the ipchains bytecounter. Works good since over a year.

Now I want to count also my tunneled IPv6 traffic. I've installed 2 rules 
in a new chain:

IPBASIC="IPv4 address of tunnel's Ethernet interface"

ipchains -N ipaccV6
ipchains -A input  -p 41 -d $IPBASIC -j ipaccV6
ipchains -A output -p 41 -s $IPBASIC -j ipaccV6
ipchains -A ipaccV6 -j ACCEPT

The basic chains are all end with a deny/reject log, also the policy is 
similiar. Forwarding similar.

Now the strange behavior:
The input related chain counts packets, the outgoing not!

Is it possible, that the ipchains outgoing ruleset did not work for 
tunneled IPv6 packets?

Here an IPv4-tcpdump only output from a ping6 via that tunnel


17:47:58.777634 eth0 < 6BONE.UNI-MUENSTER.DE > tunnel.bieringer.de: 
ip-proto-41 104
17:47:58.777634 sit0 < 0:0:0:0:0:0 0:0:0:0:0:1 ipv6 118:
* counted *

17:47:58.777882 sit0 > 0:0:0:0:0:0 0:0:0:0:0:0 ipv6 118:
17:47:58.777937 eth0 > tunnel.bieringer.de > p3E991650.dip.t-dialin.net: 
ip-proto-41 104 (DF)
* not counted*

Can someone please test such behavior?

Used: Kernel 2.2.17 + Openwall-Patch, ipchains 1.3.9, 17-Mar-1999

TIA,
	Peter


From owner-netdev@oss.sgi.com Sat Oct  7 17:49:13 2000
Received:  by oss.sgi.com id <S42180AbQJHAqY>;
	Sat, 7 Oct 2000 17:46:24 -0700
Received: from pizda.ninka.net ([216.101.162.242]:17544 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42173AbQJHAqL>;
	Sat, 7 Oct 2000 17:46:11 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id RAA02467;
	Sat, 7 Oct 2000 17:32:14 -0700
Date:   Sat, 7 Oct 2000 17:32:14 -0700
Message-Id: <200010080032.RAA02467@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     kuznet@ms2.inr.ac.ru
CC:     netdev@oss.sgi.com
In-reply-to: <200010071414.SAA30580@ms2.inr.ac.ru> (kuznet@ms2.inr.ac.ru)
Subject: Re: BUG in tcp.c ?
References:  <200010071414.SAA30580@ms2.inr.ac.ru>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   From: kuznet@ms2.inr.ac.ru
   Date: Sat, 7 Oct 2000 18:14:26 +0400 (MSK DST)

   > I've fixed it in my 2.2.x sources as well.

   Dave, sendmsg cannot be used from interrupt yet.

NBD is not desiring this, as Andi described.

Regardless, having TCP ignore sk->allocation yet datagram sockets
respect it is a real bug.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Sun Oct  8 00:34:07 2000
Received:  by oss.sgi.com id <S42187AbQJHHbR>;
	Sun, 8 Oct 2000 00:31:17 -0700
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:49426 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S42173AbQJHHaz>;
	Sun, 8 Oct 2000 00:30:55 -0700
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.9.3) with ESMTP id BAA05412
	for <netdev@oss.sgi.com>; Sun, 8 Oct 2000 01:22:51 -0700
Message-ID: <39E02EDB.4B3733CC@candelatech.com>
Date:   Sun, 08 Oct 2000 01:22:51 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Wavelan busted in 2.4.test9?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

I was looking for an example of a set_mac_address method for
my VLAN code....

wavelan was at the bottom of the grep, so I took a look:

static int wavelan_set_mac_address(device * dev, void *addr)
{
        struct sockaddr *mac = addr;

        /* Copy the address. */
        memcpy(dev->dev_addr, mac->sa_data, WAVELAN_ADDR_SIZE);

        /* Reconfigure the beast. */
        wv_82586_reconfig(dev);

        return 0;
}
#endif                          /* SET_MAC_ADDRESS */


Everything should be using net_device, not device, right?


Also, some of the examples I look at cast addr to a sockaddr (ie wavelan),
but others treat addr as the MAC.  I'm guessing that both work, but can
someone explain the more 'correct' way of doing things?

Thanks,
Ben

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Sun Oct  8 10:16:37 2000
Received:  by oss.sgi.com id <S42193AbQJHRNr>;
	Sun, 8 Oct 2000 10:13:47 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:32008 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42188AbQJHRNm>;
	Sun, 8 Oct 2000 10:13:42 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA13898; Sun, 8 Oct 2000 21:13:24 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010081713.VAA13898@ms2.inr.ac.ru>
Subject: Re: BUG in tcp.c ?
To:     davem@redhat.com (David S. Miller)
Date:   Sun, 8 Oct 2000 21:13:24 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <200010080032.RAA02467@pizda.ninka.net> from "David S. Miller" at Oct 7, 0 05:32:14 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 292       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Regardless, having TCP ignore sk->allocation yet datagram sockets
> respect it is a real bug.

No doubts. Though I would prefer not to see sk->allocation at all.

I simply felt important to warn. Some recent report about nfs
showed that people really call sendmsg from bhs.

Alexey

From owner-netdev@oss.sgi.com Sun Oct  8 13:10:27 2000
Received:  by oss.sgi.com id <S42195AbQJHUHi>;
	Sun, 8 Oct 2000 13:07:38 -0700
Received: from perninha.conectiva.com.br ([200.250.58.156]:56581 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S42188AbQJHUHW>; Sun, 8 Oct 2000 13:07:22 -0700
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id RAA08914;
	Sun, 8 Oct 2000 17:06:09 -0300
Date:   Sun, 8 Oct 2000 15:12:53 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Andi Kleen <ak@muc.de>
cc:     kuznet@ms2.inr.ac.ru, "David S. Miller" <davem@redhat.COM>,
        netdev@oss.sgi.com
Subject: Re: BUG in tcp.c ?
In-Reply-To: <20001007170147.A1657@fred.muc.de>
Message-ID: <Pine.LNX.4.21.0010081456040.11210-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


On Sat, 7 Oct 2000, Andi Kleen wrote:

> On Sat, Oct 07, 2000 at 04:16:09PM +0200, A.N.Kuznetsov wrote:
> > Hello!
> > 
> > >    2.2.17 is broken too. 
> > > 
> > > I've fixed it in my 2.2.x sources as well.
> > 
> > Dave, sendmsg cannot be used from interrupt yet.
> > Even in 2.2 it works sometimes, but surely will crash sometimes (f.e.
> > because of socket lock on interrupt).
> > 
> > If some caller needs this, I am sure, it is buggy.
> 
> iirc nbd doesn't need it from an interrupt but just to avoid deadlock
> on low memory situations when you swap over it.
> 
> Of course it is still broken because there are enough other problems
> with swapping over TCP :-)

The deadlock can happen under normal (without swapping) nbd usage: 

nbd_do_request -> nbd_send_req -> nbd_xmit -> sock_sendmsg -> ... ->
tcp_do_sendmsg -> sock_wmalloc_err(GFP_KERNEL) -> alloc_skb ->
kmalloc(GFP_KERNEL) -> kmem_cache_grow -> get_free_pages ->
try_to_free_pages -> shrink_mmap -> try_to_free_buffers ->
sync_page_buffers -> ll_rw_block -> make_request -> add_request ->
nbd_do_request -> nbd_send_req -> ... 

until there are no more free requests on the request queue and writer
processes stuck on __get_request_wait.



From owner-netdev@oss.sgi.com Sun Oct  8 14:17:39 2000
Received:  by oss.sgi.com id <S42197AbQJHVOt>;
	Sun, 8 Oct 2000 14:14:49 -0700
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:16391 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S42188AbQJHVO2>;
	Sun, 8 Oct 2000 14:14:28 -0700
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.9.3) with ESMTP id OAA19738;
	Sun, 8 Oct 2000 14:10:24 -0700
Message-ID: <39E0E2C0.559EE3F3@candelatech.com>
Date:   Sun, 08 Oct 2000 14:10:24 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     VLAN Mailing List <vlan@Scry.WANfear.com>,
        "vlan-devel (other)" <vlan-devel@lists.sourceforge.net>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Some more questions on multicast & VLAN.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


I'm having some fun trying to figure out how to make MultiCast work with
VLANs.

First, the MC list on the VLAN will not necessarily be equal to that of
the real Ethernet device, because there could be several VLAN devices,
each with a non-overlapping subset of MC addresses, on a single Ethernet
device.

Also, using VLANs does not mean that you cannot use the real Ethernet
device at the same time, so it becomes almost impossible to know when
to delete an MC address based on what is told to the VLAN device.
(Maybe it was added on the real ethernet device, as well as the VLAN
device, so removing it from the VLAN device SHOULD NOT remove it from
the ethernet device...)

Unless reference counting on the MC entries is put into place (or
already exists??)...then I should be able to delete from the
underlying device smartly...

Can somone comment on what these variables mean?:  (from net_device.h)

/*
 *	We tag multicasts with these structures.
 */
 
struct dev_mc_list
{	
	struct dev_mc_list	*next;
	__u8			dmi_addr[MAX_ADDR_LEN];
	unsigned char		dmi_addrlen;
	int			dmi_users;
	int			dmi_gusers;
};


**********************************************************************
So, here is my plan: (w/out ref-counting)

Upon an addition of an MC address to a VLAN:
  1) Update the VLAN's MC list accordingly.
  2) Add it to the underlying Ethernet device if it does not already exist.

Upon Deletion of an MC address from a VLAN device:
  1) Remove it from the VLAN device, but DO NOT remove it from the
     underlying device.  If you want it removed from the underlying
     device, then you'll have to remove it from the Ethernet device
     yourself.

NOTE:  Might have to hack up the Ethernet MC delete code too, or
    VLANs may be thinking they are accepting MC pkts that the
    underlying device IS NOT accepting.

NOTE:  If you have a large number of VLAN interfaces, keeping the
    MC list sane could be pretty time consuming (linear on number of
    VLAN interfaces + MC list for each VLAN interface...at least).
    
    How often are the MC lists expected to change??

Upon ingress of a packet to a VLAN device:
  1) Do software multicast filtering.  Anyone point me to some code
     that does multicast filtering, or an algorithm to do it? (I'm
     a little fuzzy on how MC works...)


Thanks,
Ben

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Sun Oct  8 22:05:15 2000
Received:  by oss.sgi.com id <S42206AbQJIFC0>;
	Sun, 8 Oct 2000 22:02:26 -0700
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:54280 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S42196AbQJIFCK>;
	Sun, 8 Oct 2000 22:02:10 -0700
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.9.3) with ESMTP id WAA25172;
	Sun, 8 Oct 2000 22:54:13 -0700
Message-ID: <39E15D85.B51159A4@candelatech.com>
Date:   Sun, 08 Oct 2000 22:54:13 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>,
        VLAN Mailing List <vlan@Scry.WANfear.com>
Subject: dev_get_by_name, index
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>From looking at the 2.4.test9 code in dev.c, the device lookups by
both name and index are linear on the number of devices.  It
seems to me that hashing them would make more sense, especially
since VLAN, ATM, FrameRelay and other technologies requires a potentially
large number of interfaces...

I was thinking of leaving the dev_base list alone, but keeping a hashtable
for lookup_by_name and lookup_by_index too.  I can add a small piece of code
near the code that currently inserts into the dev_base list that will also
insert the device into the hash tables.  Code to remove them will be put
in place too.

Then, in methods like dev.c's: struct net_device * __dev_get_by_index(int ifindex)
I'll use a hashed lookup instead of the linear list search currently used...

So, does this seem like something worth doing?

Is there some generic hash-table code already in the kernel somewhere,
or do I get to build my own?  (It shouldn't be too difficult :))

Any problems you see, or think I should be wary of?

Thanks,
Ben

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Mon Oct  9 02:06:37 2000
Received:  by oss.sgi.com id <S42207AbQJIJG1>;
	Mon, 9 Oct 2000 02:06:27 -0700
Received: from spock.linux.it ([151.99.137.27]:16115 "HELO spock.linux.it")
	by oss.sgi.com with SMTP id <S42196AbQJIJGI>;
	Mon, 9 Oct 2000 02:06:08 -0700
Received: by spock.linux.it (Postfix, from userid 10)
	id 592CE197BC; Mon,  9 Oct 2000 11:06:02 +0200 (CEST)
Received: from giano with UUCP (rmail); Mon,  9 Oct 2000 11:06:01 +0200
Received: by giano.linux.it (Postfix, from userid 10)
	id AF1DE3769; Mon,  9 Oct 2000 11:03:36 +0200 (CEST)
Received: by wonderland.linux.it (Postfix/Md, from userid 1001)
	id 2B8C217E4D; Mon,  9 Oct 2000 10:26:15 +0200 (CEST)
Date:   Mon, 9 Oct 2000 10:26:15 +0200
From:   Marco d'Itri <md@linux.it>
To:     netdev@oss.sgi.com
Cc:     debian-ipv6@lists.debian.org
Subject: Re: Autoconfiguration
Message-ID: <20001009102615.A839@wonderland.linux.it>
References: <20001008201945.B64012@seanrees.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001008201945.B64012@seanrees.com>; from sean@seanrees.com on Sun, Oct 08, 2000 at 08:19:45PM -0700
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Oct 09, Sean-Paul Rees <sean@seanrees.com> wrote:

[this happens with 2.4 kernels and did NOT happen with 2.2 kernels]

 >I just installed potato today (and later upgraded to woody) on my i686. I also
 >upgraded to kernel 2.4.0-test8, compiling in IPv6 support. For some reason,
 >I get the following message in the system log:
 >eth0: no IPv6 routers present
 >
 >I don't know what is causing it, especially since I know for a fact
 >that there is an IPv6 router present (my other boxes [although
 >FreeBSD]) configure to it just fine.

The ugly thing is that a bogus default route to eth0 will be created,
and if you don't have any tunnel configured connections to dual stack
hosts will hang waiting for the timeout instead of immediately trying
the v4 address.

Why such change?
How can I disable this annoying feature? I had to put this in my rc
scripts to work around it:

( sleep 30; ip -6 ro del default dev dummy0 ) &

-- 
ciao,
Marco



From owner-netdev@oss.sgi.com Mon Oct  9 06:13:10 2000
Received:  by oss.sgi.com id <S42203AbQJINM7>;
	Mon, 9 Oct 2000 06:12:59 -0700
Received: from gb.bnet.pl ([212.160.188.33]:14575 "HELO nic.nigdzie")
	by oss.sgi.com with SMTP id <S42196AbQJINMq>;
	Mon, 9 Oct 2000 06:12:46 -0700
Received: (qmail 3248 invoked by uid 500); 6 Oct 2000 17:27:37 -0000
Date:   Fri, 6 Oct 2000 19:27:36 +0200
From:   Jacek Konieczny <jajcus@zeus.polsl.gliwice.pl>
To:     netdev@oss.sgi.com
Cc:     Moter Du <Moter_Du@stsl.siemens.com.tw>
Subject: Re: linux-2.2.17 auto-configuration
Message-ID: <20001006192736.A3207@nic.nigdzie>
References: <C6BEA88DAF6AD31185F500105A835CBB01BAC139@stslex.siemens.com.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.11i
In-Reply-To: <C6BEA88DAF6AD31185F500105A835CBB01BAC139@stslex.siemens.com.tw>; from Moter_Du@stsl.siemens.com.tw on Fri, Oct 06, 2000 at 05:55:01PM +0800
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Oct 06, 2000 at 05:55:01PM +0800, Moter Du wrote:
> I'm confused by auto-configuration in linux-2.2.17. In summary it seems
> Linux supports only solicited auto-configuration, not unsolicited
> auto-configuration. The term 'solicited auto-configuration' means Linux
> sends a RS and Router replies a RA. The term 'unsolicited
> auto-configuration' means Router advertises a RA periodically. In the latter
> case Linux does receive the RA, but it never auto-configured itself.
> 
> I should trace into the kernel. But if some can point out the answer I would
> appreciate very much.
Some time ago I have sent here (and to one of IPv6 maintainers) a patch
fixing 2.2.x-kernel auto-configuration bug. It seems it was not included
in 2.2.17 kernel.

The problem I was fixing was "disapearing" "all-nodes" multicast
address. After the interface went down and up it lost the ff02::1
multicast address and it received no RA. After removing and loading the
module it would come back and auto-configuration worked again.

I hope this helps.

Greets,
        Jacek 


From owner-netdev@oss.sgi.com Mon Oct  9 13:26:12 2000
Received:  by oss.sgi.com id <S42223AbQJIU0C>;
	Mon, 9 Oct 2000 13:26:02 -0700
Received: from kogge.hanse.de ([192.76.134.17]:16903 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42213AbQJIUZq>;
	Mon, 9 Oct 2000 13:25:46 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id WAA01945;
	Mon, 9 Oct 2000 22:29:31 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id WAA12465;
	Mon, 9 Oct 2000 22:11:08 +0200
To:     kuznet@ms2.inr.ac.ru
cc:     riel@conectiva.com.br, davem@redhat.com, netdev@oss.sgi.com
Subject: Re: BUG in tcp.c ?
References: <200010071414.SAA30580@ms2.inr.ac.ru>
From:   Henner Eisen <eis@baty.hanse.de>
Date:   09 Oct 2000 22:11:08 +0200
In-Reply-To: kuznet@ms2.inr.ac.ru's message of "Sat, 7 Oct 2000 18:14:26 +0400 (MSK DST)"
Message-ID: <oud7h9kc6b.fsf@baty.hanse.de>
Lines:  27
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "kuznet" == kuznet  <kuznet@ms2.inr.ac.ru> writes:

    kuznet> Hello!
    >> 2.2.17 is broken too.
    >> 
    >> I've fixed it in my 2.2.x sources as well.

    kuznet> Dave, sendmsg cannot be used from interrupt yet.  Even in
    kuznet> 2.2 it works sometimes, but surely will crash sometimes
    kuznet> (f.e.  because of socket lock on interrupt).

I´ve used the similar trick (resetting sk->allocation to GFP_ATOMIC)
for IP/PPP tunneling over X.25 when I needed to temporarily turn
sock_alloc_send_skb() into a function callable from bh context.
However, just resetting sk->allocation is not sufficient.

In order to make sock_alloc_send_skb() non-blocking under any circumstances,
it was also necessary to set so->sndtimeo to 0. (sock_alloc_send_skb()
will never enter sock_wait_for_wmem() if timeo is 0).

nbd.c does not play the latter trick. Even if it did, tcp does not use
sock_alloc_send_skb(). And from a first look at tcp.c, it seems that
wait_for_tcp_mem() might add itsself to the wait queue even if so->sndtimeo
is 0.

Henner


From owner-netdev@oss.sgi.com Mon Oct  9 13:39:51 2000
Received:  by oss.sgi.com id <S42224AbQJIUjb>;
	Mon, 9 Oct 2000 13:39:31 -0700
Received: from brutus.conectiva.com.br ([200.250.58.146]:7672 "EHLO
        brutus.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S42213AbQJIUjP>; Mon, 9 Oct 2000 13:39:15 -0700
Received: from localhost (riel@localhost)
	by brutus.conectiva.com.br (8.10.2/8.10.2) with ESMTP id e99KceT05445;
	Mon, 9 Oct 2000 17:38:40 -0300
X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs
Date:   Mon, 9 Oct 2000 17:38:40 -0300 (BRST)
From:   Rik van Riel <riel@conectiva.com.br>
X-Sender: riel@duckman.distro.conectiva
To:     Henner Eisen <eis@baty.hanse.de>
cc:     kuznet@ms2.inr.ac.ru, davem@redhat.com, netdev@oss.sgi.com
Subject: Re: BUG in tcp.c ?
In-Reply-To: <oud7h9kc6b.fsf@baty.hanse.de>
Message-ID: <Pine.LNX.4.21.0010091734241.1562-100000@duckman.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On 9 Oct 2000, Henner Eisen wrote:
> >>>>> "kuznet" == kuznet  <kuznet@ms2.inr.ac.ru> writes:
> 
>     kuznet> Hello!
>     >> 2.2.17 is broken too.
>     >> 
>     >> I've fixed it in my 2.2.x sources as well.
> 
>     kuznet> Dave, sendmsg cannot be used from interrupt yet.  Even in
>     kuznet> 2.2 it works sometimes, but surely will crash sometimes
>     kuznet> (f.e.  because of socket lock on interrupt).
> 
> I´ve used the similar trick (resetting sk->allocation to
> GFP_ATOMIC) for IP/PPP tunneling over X.25 when I needed to
> temporarily turn sock_alloc_send_skb() into a function callable
> from bh context. However, just resetting sk->allocation is not
> sufficient.
> 
> In order to make sock_alloc_send_skb() non-blocking under any
> circumstances, it was also necessary to set so->sndtimeo to 0.
> (sock_alloc_send_skb() will never enter sock_wait_for_wmem() if
> timeo is 0).
> 
> nbd.c does not play the latter trick. Even if it did, tcp does
> not use sock_alloc_send_skb(). And from a first look at tcp.c,
> it seems that wait_for_tcp_mem() might add itsself to the wait
> queue even if so->sndtimeo is 0.

Hmmm, so we will need some surgery in the TCP (and IP?) code
to make swap-over-network a reality ? 

If it /should/ be ok (according to the network folks), I'll
probably dig in and try to fix it, but if it will take some
deep surgery, I'll probably wait until I've fixed some other,
more urgent, VM issues ...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/


From owner-netdev@oss.sgi.com Mon Oct  9 20:11:03 2000
Received:  by oss.sgi.com id <S42229AbQJJDKd>;
	Mon, 9 Oct 2000 20:10:33 -0700
Received: from [209.140.64.7] ([209.140.64.7]:57260 "HELO mail.inconnect.com")
	by oss.sgi.com with SMTP id <S42213AbQJJDKK>;
	Mon, 9 Oct 2000 20:10:10 -0700
Received: (qmail 23087 invoked from network); 10 Oct 2000 03:08:33 -0000
Received: from ultra1.inconnect.com (209.140.64.2)
  by mail with SMTP; 10 Oct 2000 03:08:33 -0000
Date:   Mon, 9 Oct 2000 21:08:33 -0600 (MDT)
From:   Keyshaun <thekernel@subdimension.com>
X-Sender: kruger@ultra1.inconnect.com
To:     Linux Netdev <netdev@oss.sgi.com>
Subject: Gilat2Home
Message-ID: <Pine.SOL.4.21.0010092059590.14456-100000@ultra1.inconnect.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi, I am trying to get the info to write a driver for gilat2home.  I have
only one unidentified device.  

The PCI dump I acquired from a system with the network cards in it
returned 3 PCI network device entries,all other entries were from the
sound card or the Intel chipsets Vendor ID 0x8086.  The system has
ethernet onboard so I will disregard the third net interface that claims
to be a 3Com.

Now I have 2 devices left.  One is the PLX PCI9080 network interface.  I
know nothing of this, but I will be looking for it in the kernel source.  
The last device is unknown.  Vendor ID=14f3, Device ID=2030.  

I need to find out where to find the main registrar of PCI Vendor IDs.  I
can't just go to the company that makes it and ask for info to write a
linux driver.  They are funded by Microsoft.  When I called their US
offices I was told that they are instructed to never give out docs for
writing a Linux driver, hence I need to find the info another way.

Shaun Kruger


From owner-netdev@oss.sgi.com Mon Oct  9 20:42:43 2000
Received:  by oss.sgi.com id <S42221AbQJJDmd>;
	Mon, 9 Oct 2000 20:42:33 -0700
Received: from kanga.kvack.org ([209.82.47.3]:36105 "EHLO kanga.kvack.org")
	by oss.sgi.com with ESMTP id <S42213AbQJJDmH>;
	Mon, 9 Oct 2000 20:42:07 -0700
Received: (from localhost user: 'blah', uid#63042) by kanga.kvack.org
	with SMTP id <S131166AbQJJDkS>; Mon, 9 Oct 2000 23:40:18 -0400
Date:   Mon, 9 Oct 2000 23:40:18 -0400 (EDT)
From:   "Benjamin C.R. LaHaise" <blah@kvack.org>
To:     Keyshaun <thekernel@subdimension.com>
cc:     Linux Netdev <netdev@oss.sgi.com>
Subject: Re: Gilat2Home
In-Reply-To: <Pine.SOL.4.21.0010092059590.14456-100000@ultra1.inconnect.com>
Message-ID: <Pine.LNX.3.96.1001009233635.4877B-100000@kanga.kvack.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, 9 Oct 2000, Keyshaun wrote:

> Now I have 2 devices left.  One is the PLX PCI9080 network interface.  I
> know nothing of this, but I will be looking for it in the kernel source.  
> The last device is unknown.  Vendor ID=14f3, Device ID=2030.  

The PLX PCI9080 is a glue chip that bridges PCI to a local bus compatible
with most CPUs (I've worked on cards where it was tied to 68000 series
and i960 processors).  Its PCI ids are programmable and stored on an
EEPROM on the board, the the PLX chip will handle DMA to/from the onboard 
memory or devices.  What other chips are on the card?

		-ben


From owner-netdev@oss.sgi.com Mon Oct  9 21:08:22 2000
Received:  by oss.sgi.com id <S42214AbQJJEIN>;
	Mon, 9 Oct 2000 21:08:13 -0700
Received: from battlejitney.wdhq.scyld.com ([216.254.93.178]:65521 "EHLO
        vaio.greennet") by oss.sgi.com with ESMTP id <S42213AbQJJEHo>;
	Mon, 9 Oct 2000 21:07:44 -0700
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id AAA25263;
	Tue, 10 Oct 2000 00:08:34 -0400
Date:   Tue, 10 Oct 2000 00:08:34 -0400 (EDT)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     Keyshaun <thekernel@subdimension.com>
cc:     Linux Netdev <netdev@oss.sgi.com>
Subject: Re: Gilat2Home
In-Reply-To: <Pine.SOL.4.21.0010092059590.14456-100000@ultra1.inconnect.com>
Message-ID: <Pine.LNX.4.10.10010092335390.9348-100000@vaio.greennet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, 9 Oct 2000, Keyshaun wrote:

> Hi, I am trying to get the info to write a driver for gilat2home.  I have
> only one unidentified device.  
...
> Now I have 2 devices left.  One is the PLX PCI9080 network interface.  I
> know nothing of this, but I will be looking for it in the kernel source.  

The PLX chips are generic PCI interface chips.
They can be programmed to bridge to a generic bus, for instance to update an
old ISA-like design to PCI.

They are relatively expensive chips, so you will only find them on low
production volume devices where they couldn't justify the engineering cost
for a real design update.

> I need to find out where to find the main registrar of PCI Vendor IDs.  I
> can't just go to the company that makes it and ask for info to write a
> linux driver.  They are funded by Microsoft.  When I called their US
> offices I was told that they are instructed to never give out docs for
> writing a Linux driver, hence I need to find the info another way.

If the NIC is really behind the PLX chip it will be difficult to figure out
how it works.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993


From owner-netdev@oss.sgi.com Mon Oct  9 23:49:24 2000
Received:  by oss.sgi.com id <S42233AbQJJGtD>;
	Mon, 9 Oct 2000 23:49:03 -0700
Received: from mail.inconnect.com ([209.140.64.7]:44243 "HELO
        mail.inconnect.com") by oss.sgi.com with SMTP id <S42213AbQJJGse>;
	Mon, 9 Oct 2000 23:48:34 -0700
Received: (qmail 19827 invoked from network); 10 Oct 2000 06:47:53 -0000
Received: from ultra1.inconnect.com (209.140.64.2)
  by mail with SMTP; 10 Oct 2000 06:47:53 -0000
Date:   Tue, 10 Oct 2000 00:47:53 -0600 (MDT)
From:   Keyshaun <thekernel@subdimension.com>
X-Sender: kruger@ultra1.inconnect.com
To:     Donald Becker <becker@scyld.com>
cc:     Linux Netdev <netdev@oss.sgi.com>
Subject: Re: Gilat2Home
In-Reply-To: <Pine.LNX.4.10.10010092335390.9348-100000@vaio.greennet>
Message-ID: <Pine.SOL.4.21.0010100043520.14456-100000@ultra1.inconnect.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

ARGH...  I did some reading and I found the databook on the PLX.  I'm
going to approach them and lead them to believe I am a windows user
seeking debugging info.  I can probably blame it on a device
conflict.  Windows is famous for croaking on those.  I need this internet
service and I just don't want to use windows as a router.  It goes against
everything I use linux for.

On another note, is there a common interface for USB network
devices?  Gilat2Home will soon be available in an external USB unit.  (I
don't know why they don't just output ethernet)

Shaun Kruger

On Tue, 10 Oct 2000, Donald Becker wrote:

> On Mon, 9 Oct 2000, Keyshaun wrote:
> 
> > Hi, I am trying to get the info to write a driver for gilat2home.  I have
> > only one unidentified device.  
> ...
> > Now I have 2 devices left.  One is the PLX PCI9080 network interface.  I
> > know nothing of this, but I will be looking for it in the kernel source.  
> 
> The PLX chips are generic PCI interface chips.
> They can be programmed to bridge to a generic bus, for instance to update an
> old ISA-like design to PCI.
> 
> They are relatively expensive chips, so you will only find them on low
> production volume devices where they couldn't justify the engineering cost
> for a real design update.
> 
> > I need to find out where to find the main registrar of PCI Vendor IDs.  I
> > can't just go to the company that makes it and ask for info to write a
> > linux driver.  They are funded by Microsoft.  When I called their US
> > offices I was told that they are instructed to never give out docs for
> > writing a Linux driver, hence I need to find the info another way.
> 
> If the NIC is really behind the PLX chip it will be difficult to figure out
> how it works.
> 
> Donald Becker				becker@scyld.com
> Scyld Computing Corporation		http://www.scyld.com
> 410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
> Annapolis MD 21403			410-990-9993
> 


From owner-netdev@oss.sgi.com Tue Oct 10 01:45:13 2000
Received:  by oss.sgi.com id <S42234AbQJJIox>;
	Tue, 10 Oct 2000 01:44:53 -0700
Received: from gleb.nbase.co.il ([194.90.136.56]:29188 "EHLO gleb.nbase.co.il")
	by oss.sgi.com with ESMTP id <S42213AbQJJIob>;
	Tue, 10 Oct 2000 01:44:31 -0700
Received: (from gleb@localhost)
	by gleb.nbase.co.il (8.11.0/8.11.0/Debian 8.11.0-6) id e9A8gN108883;
	Tue, 10 Oct 2000 10:42:23 +0200
From:   Gleb Natapov <gleb@nbase.co.il>
Date:   Tue, 10 Oct 2000 10:42:23 +0200
To:     vlan-devel@lists.sourceforge.net
Cc:     VLAN Mailing List <vlan@Scry.WANfear.com>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: [Vlan-devel] Some more questions on multicast & VLAN.
Message-ID: <20001010104223.A8550@nbase.co.il>
References: <39E0E2C0.559EE3F3@candelatech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <39E0E2C0.559EE3F3@candelatech.com>; from greearb@candelatech.com on Sun, Oct 08, 2000 at 02:10:24PM -0700
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello Ben,

On Sun, Oct 08, 2000 at 02:10:24PM -0700, Ben Greear wrote:
> 
> I'm having some fun trying to figure out how to make MultiCast work with
> VLANs.
> 
> First, the MC list on the VLAN will not necessarily be equal to that of
> the real Ethernet device, because there could be several VLAN devices,
> each with a non-overlapping subset of MC addresses, on a single Ethernet
> device.

Right.

> 
> Also, using VLANs does not mean that you cannot use the real Ethernet
> device at the same time, so it becomes almost impossible to know when
> to delete an MC address based on what is told to the VLAN device.
> (Maybe it was added on the real ethernet device, as well as the VLAN
> device, so removing it from the VLAN device SHOULD NOT remove it from
> the ethernet device...)

Here I don't agree with you completely. It is possible to know when to delete or add MC address
from/to ethernet device.

Here how we do it in our implementation: 
 set_multicast_list is called whenever MC address is added or deleted from device's mc_list. 
I store previous mc_list in vlan private structure. When set_multicast_list is called I check for
addresses that are not on saved mc_list and add them to the ethernet device. After that I check for 
addresses that are on the saved mc_list but not on vlan mc_list and delete them from the device.
Than I save new device's mc_list in vlan private structure.

 Unfortunately current multicast address management API isn't convenient for use with virtual devices.
Perhaps now is a good time to change it. I personally want to see two functions: 
dev->add_multicast_address(), dev->del_multicast_address(). This way it will be much easier for virtual
devices to manage underlying devices' MC list.

--
			Gleb.

From owner-netdev@oss.sgi.com Tue Oct 10 08:03:16 2000
Received:  by oss.sgi.com id <S42240AbQJJPDG>;
	Tue, 10 Oct 2000 08:03:06 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:1553 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42215AbQJJPCi>;
	Tue, 10 Oct 2000 08:02:38 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA14198; Tue, 10 Oct 2000 19:01:11 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010101501.TAA14198@ms2.inr.ac.ru>
Subject: Re: BUG in tcp.c ?
To:     eis@baty.hanse.de (Henner Eisen)
Date:   Tue, 10 Oct 2000 19:01:11 +0400 (MSK DST)
Cc:     riel@conectiva.com.br, davem@redhat.com, netdev@oss.sgi.com
In-Reply-To: <oud7h9kc6b.fsf@baty.hanse.de> from "Henner Eisen" at Oct 9, 0 10:11:08 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 774       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> sock_alloc_send_skb() into a function callable from bh context.
> However, just resetting sk->allocation is not sufficient.

No doubts. It is exaclty, which I wanted to say.


> In order to make sock_alloc_send_skb() non-blocking under any circumstances,
> it was also necessary to set so->sndtimeo to 0. (sock_alloc_send_skb()
> will never enter sock_wait_for_wmem() if timeo is 0).

Sorry? This thing is called O_NONBLOCK. sndtimeo is additional baroque
detail, which is not used provided you do not touch it. Do not touch it.


> nbd.c does not play the latter trick.

Nobody needs to play such tricks.


What's about calling from interrupts (not the case with nbd),
no tricks will help. It is simply impossible to use top level
syscall from interrupt.

Alexey

From owner-netdev@oss.sgi.com Tue Oct 10 08:05:55 2000
Received:  by oss.sgi.com id <S42241AbQJJPFg>;
	Tue, 10 Oct 2000 08:05:36 -0700
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:8457 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S42215AbQJJPFY>;
	Tue, 10 Oct 2000 08:05:24 -0700
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.9.3) with ESMTP id IAA12499;
	Tue, 10 Oct 2000 08:56:45 -0700
Message-ID: <39E33C3D.873C5D3D@candelatech.com>
Date:   Tue, 10 Oct 2000 08:56:45 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Gleb Natapov <gleb@nbase.co.il>
CC:     vlan-devel@lists.sourceforge.net,
        VLAN Mailing List <vlan@Scry.WANfear.com>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: [Vlan-devel] Some more questions on multicast & VLAN.
References: <39E0E2C0.559EE3F3@candelatech.com> <20001010104223.A8550@nbase.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Gleb Natapov wrote:
> 
> Hello Ben,
> 
> On Sun, Oct 08, 2000 at 02:10:24PM -0700, Ben Greear wrote:
> >
> > I'm having some fun trying to figure out how to make MultiCast work with
> > VLANs.
> >
> > First, the MC list on the VLAN will not necessarily be equal to that of
> > the real Ethernet device, because there could be several VLAN devices,
> > each with a non-overlapping subset of MC addresses, on a single Ethernet
> > device.
> 
> Right.
> 
> >
> > Also, using VLANs does not mean that you cannot use the real Ethernet
> > device at the same time, so it becomes almost impossible to know when
> > to delete an MC address based on what is told to the VLAN device.
> > (Maybe it was added on the real ethernet device, as well as the VLAN
> > device, so removing it from the VLAN device SHOULD NOT remove it from
> > the ethernet device...)
> 
> Here I don't agree with you completely. It is possible to know when to delete or add MC address
> from/to ethernet device.
> 
> Here how we do it in our implementation:
>  set_multicast_list is called whenever MC address is added or deleted from device's mc_list.
> I store previous mc_list in vlan private structure. When set_multicast_list is called I check for
> addresses that are not on saved mc_list and add them to the ethernet device. After that I check for
> addresses that are on the saved mc_list but not on vlan mc_list and delete them from the device.
> Than I save new device's mc_list in vlan private structure.

Yes, after re-reading your code about 20 more times I finally realized that is what
you were doing.  (Actually, I started doing the same thing..then realized you had
already figured it out..so I just used yours... :))

You mentioned that there was a race condition when using SMP, could you explain
that one a bit more?  We could probably put a lock around it if we need to, in
order to make it safe.


> 
>  Unfortunately current multicast address management API isn't convenient for use with virtual devices.
> Perhaps now is a good time to change it. I personally want to see two functions:
> dev->add_multicast_address(), dev->del_multicast_address(). This way it will be much easier for virtual
> devices to manage underlying devices' MC list.

Probably a good 2.5 thing...

> 
> --
>                         Gleb.

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Tue Oct 10 08:12:15 2000
Received:  by oss.sgi.com id <S42243AbQJJPMG>;
	Tue, 10 Oct 2000 08:12:06 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:6161 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42215AbQJJPLs>;
	Tue, 10 Oct 2000 08:11:48 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA14300; Tue, 10 Oct 2000 19:10:50 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010101510.TAA14300@ms2.inr.ac.ru>
Subject: Re: BUG in tcp.c ?
To:     riel@conectiva.com.br (Rik van Riel)
Date:   Tue, 10 Oct 2000 19:10:50 +0400 (MSK DST)
Cc:     eis@baty.hanse.de, davem@redhat.com, netdev@oss.sgi.com
In-Reply-To: <Pine.LNX.4.21.0010091734241.1562-100000@duckman.distro.conectiva> from "Rik van Riel" at Oct 9, 0 05:38:40 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 390       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Hmmm, so we will need some surgery in the TCP (and IP?) code
> to make swap-over-network a reality ? 

I hope that note was irrelevant.


> deep surgery, I'll probably wait until I've fixed some other,
> more urgent, VM issues ...

I do not think that it is urgent. sk->allocation cures nbd.
But the most possibility of dead loop in try_to_free_pages()
opens a flaw, yes.

Alexey

From owner-netdev@oss.sgi.com Tue Oct 10 08:16:16 2000
Received:  by oss.sgi.com id <S42246AbQJJPQG>;
	Tue, 10 Oct 2000 08:16:06 -0700
Received: from brutus.conectiva.com.br ([200.250.58.146]:5874 "EHLO
        brutus.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S42245AbQJJPPq>; Tue, 10 Oct 2000 08:15:46 -0700
Received: from localhost (riel@localhost)
	by brutus.conectiva.com.br (8.10.2/8.10.2) with ESMTP id e9AFEfC11302;
	Tue, 10 Oct 2000 12:14:41 -0300
X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs
Date:   Tue, 10 Oct 2000 12:14:41 -0300 (BRST)
From:   Rik van Riel <riel@conectiva.com.br>
X-Sender: riel@duckman.distro.conectiva
To:     kuznet@ms2.inr.ac.ru
cc:     eis@baty.hanse.de, davem@redhat.com, netdev@oss.sgi.com
Subject: Re: BUG in tcp.c ?
In-Reply-To: <200010101510.TAA14300@ms2.inr.ac.ru>
Message-ID: <Pine.LNX.4.21.0010101212520.11122-100000@duckman.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, 10 Oct 2000 kuznet@ms2.inr.ac.ru wrote:

> > Hmmm, so we will need some surgery in the TCP (and IP?) code
> > to make swap-over-network a reality ? 
> 
> I hope that note was irrelevant.

So do I, but maybe there are more hidden traps to get stuff
working /reliably/ ...

> > deep surgery, I'll probably wait until I've fixed some other,
> > more urgent, VM issues ...
> 
> I do not think that it is urgent. sk->allocation cures nbd.
> But the most possibility of dead loop in try_to_free_pages()
> opens a flaw, yes.

It's not a /very/ urgent thing, but there are some people out
there using Linux on diskless machines who /would/ like to
have the ability to use swap space from those machines...

(and if the TCP/IP issues aren't that hard, I'll try and work
out the VM issues involved with this problem)

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/


From owner-netdev@oss.sgi.com Tue Oct 10 08:50:26 2000
Received:  by oss.sgi.com id <S42242AbQJJPuH>;
	Tue, 10 Oct 2000 08:50:07 -0700
Received: from gleb.nbase.co.il ([194.90.136.56]:25362 "EHLO gleb.nbase.co.il")
	by oss.sgi.com with ESMTP id <S42215AbQJJPtj>;
	Tue, 10 Oct 2000 08:49:39 -0700
Received: (from gleb@localhost)
	by gleb.nbase.co.il (8.11.0/8.11.0/Debian 8.11.0-6) id e9AFm7u01066;
	Tue, 10 Oct 2000 17:48:07 +0200
From:   Gleb Natapov <gleb@nbase.co.il>
Date:   Tue, 10 Oct 2000 17:48:06 +0200
To:     Ben Greear <greearb@candelatech.com>
Cc:     vlan-devel@lists.sourceforge.net,
        VLAN Mailing List <vlan@Scry.WANfear.com>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: [Vlan-devel] Some more questions on multicast & VLAN.
Message-ID: <20001010174806.A967@nbase.co.il>
References: <39E0E2C0.559EE3F3@candelatech.com> <20001010104223.A8550@nbase.co.il> <39E33C3D.873C5D3D@candelatech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <39E33C3D.873C5D3D@candelatech.com>; from greearb@candelatech.com on Tue, Oct 10, 2000 at 08:56:45AM -0700
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, Oct 10, 2000 at 08:56:45AM -0700, Ben Greear wrote:
>
[...]
> You mentioned that there was a race condition when using SMP, could you explain
> that one a bit more?  We could probably put a lock around it if we need to, in
> order to make it safe.

 Not a race condition, but deadlock. Look at linux/net/core/dev_mcast.c. VLAN set_multicast_list()
function is called from dev_mc_upload() while holding dev_mc_lock. When you try to add or delete
MC address to/from underlying device from your set_multicast_list() you call dev_mc_{delete,add} 
and they also try to grab the same lock, oops deadlock ;)

--
			Gleb.

From owner-netdev@oss.sgi.com Tue Oct 10 09:00:56 2000
Received:  by oss.sgi.com id <S42244AbQJJQAq>;
	Tue, 10 Oct 2000 09:00:46 -0700
Received: from canospam.agcs.com ([130.131.166.29]:63920 "EHLO
        canospam.agcs.com") by oss.sgi.com with ESMTP id <S42215AbQJJQAZ>;
	Tue, 10 Oct 2000 09:00:25 -0700
Received: from frontier. (marshal.agcs.com [130.131.60.2])
	by canospam.agcs.com (8.9.3/8.9.1) with SMTP id IAA09401
	for <netdev@oss.sgi.com>; Tue, 10 Oct 2000 08:59:23 -0700 (MST)
Posted-Date: Tue, 10 Oct 2000 08:59:23 -0700 (MST)
Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5])
	by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id IAA19754
	for <netdev@oss.sgi.com>; Tue, 10 Oct 2000 08:58:09 -0700 (MST)
Received: from agcs.com ([130.131.166.110]) by pxmail1.agcs.com
          (Netscape Messaging Server 3.61)  with ESMTP id AAA17C7;
          Tue, 10 Oct 2000 08:58:39 -0700
Message-ID: <39E33CAF.1F9C51E2@agcs.com>
Date:   Tue, 10 Oct 2000 08:58:39 -0700
From:   Ben Greear <greearb@agcs.com>
Reply-To: greearb@agcs.com
Organization: AG Communication Systems
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To:     Gleb Natapov <gleb@nbase.co.il>
CC:     Ben Greear <greearb@candelatech.com>,
        vlan-devel@lists.sourceforge.net,
        VLAN Mailing List <vlan@Scry.WANfear.com>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: [Vlan-devel] Some more questions on multicast & VLAN.
References: <39E0E2C0.559EE3F3@candelatech.com> <20001010104223.A8550@nbase.co.il> <39E33C3D.873C5D3D@candelatech.com> <20001010174806.A967@nbase.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Gleb Natapov wrote:

> On Tue, Oct 10, 2000 at 08:56:45AM -0700, Ben Greear wrote:
> >
> [...]
> > You mentioned that there was a race condition when using SMP, could you explain
> > that one a bit more?  We could probably put a lock around it if we need to, in
> > order to make it safe.
>
>  Not a race condition, but deadlock. Look at linux/net/core/dev_mcast.c. VLAN set_multicast_list()
> function is called from dev_mc_upload() while holding dev_mc_lock. When you try to add or delete
> MC address to/from underlying device from your set_multicast_list() you call dev_mc_{delete,add}
> and they also try to grab the same lock, oops deadlock ;)

Make the dev_mc_lock acquisition conditional:
if (global_vlan_dev_mc_lock_already_grabbed == 1) {
  /* don't get it again, VLAN code already obtained it... */
}
else {
  /* go get the lock.. */
 ....
}

Sure, it isn't beautiful, but it might work untill the subsystem is re-worked a bit...

Ben

>
>
> --
>                         Gleb.

--
Ben Greear        greearb@agcs.com   Pager: 202-2717
(623) 581 4980    "More weight!" -- _The Crucible._
http://hydrogen:8080/home/greearb/public_html/index.html




From owner-netdev@oss.sgi.com Tue Oct 10 09:20:26 2000
Received:  by oss.sgi.com id <S42245AbQJJQT5>;
	Tue, 10 Oct 2000 09:19:57 -0700
Received: from gleb.nbase.co.il ([194.90.136.56]:28691 "EHLO gleb.nbase.co.il")
	by oss.sgi.com with ESMTP id <S42215AbQJJQTc>;
	Tue, 10 Oct 2000 09:19:32 -0700
Received: (from gleb@localhost)
	by gleb.nbase.co.il (8.11.0/8.11.0/Debian 8.11.0-6) id e9AGHSX01268;
	Tue, 10 Oct 2000 18:17:28 +0200
From:   Gleb Natapov <gleb@nbase.co.il>
Date:   Tue, 10 Oct 2000 18:17:28 +0200
To:     Ben Greear <greearb@agcs.com>
Cc:     Ben Greear <greearb@candelatech.com>,
        vlan-devel@lists.sourceforge.net,
        VLAN Mailing List <vlan@Scry.WANfear.com>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: [Vlan-devel] Some more questions on multicast & VLAN.
Message-ID: <20001010181728.A1139@nbase.co.il>
References: <39E0E2C0.559EE3F3@candelatech.com> <20001010104223.A8550@nbase.co.il> <39E33C3D.873C5D3D@candelatech.com> <20001010174806.A967@nbase.co.il> <39E33CAF.1F9C51E2@agcs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <39E33CAF.1F9C51E2@agcs.com>; from greearb@agcs.com on Tue, Oct 10, 2000 at 08:58:39AM -0700
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, Oct 10, 2000 at 08:58:39AM -0700, Ben Greear wrote:
> Gleb Natapov wrote:
> 
> > On Tue, Oct 10, 2000 at 08:56:45AM -0700, Ben Greear wrote:
> > >
> > [...]
> > > You mentioned that there was a race condition when using SMP, could you explain
> > > that one a bit more?  We could probably put a lock around it if we need to, in
> > > order to make it safe.
> >
> >  Not a race condition, but deadlock. Look at linux/net/core/dev_mcast.c. VLAN set_multicast_list()
> > function is called from dev_mc_upload() while holding dev_mc_lock. When you try to add or delete
> > MC address to/from underlying device from your set_multicast_list() you call dev_mc_{delete,add}
> > and they also try to grab the same lock, oops deadlock ;)
> 
> Make the dev_mc_lock acquisition conditional:
> if (global_vlan_dev_mc_lock_already_grabbed == 1) {
>   /* don't get it again, VLAN code already obtained it... */
> }
> else {
>   /* go get the lock.. */
>  ....
> }

This way you'll get the race condition :). Anyway, I've wrote the patch that gets rid of dev_mc_lock
and I hope it will be applied to the kernel really soon.

> 
> Sure, it isn't beautiful, but it might work untill the subsystem is re-worked a bit...
> 
--
			Gleb.

From owner-netdev@oss.sgi.com Tue Oct 10 16:27:15 2000
Received:  by oss.sgi.com id <S42280AbQJJX1F>;
	Tue, 10 Oct 2000 16:27:05 -0700
Received: from kogge.hanse.de ([192.76.134.17]:17924 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42273AbQJJX0e>;
	Tue, 10 Oct 2000 16:26:34 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id BAA03335;
	Wed, 11 Oct 2000 01:28:31 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id AAA18853;
	Wed, 11 Oct 2000 00:21:21 +0200
Date:   Wed, 11 Oct 2000 00:21:21 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200010102221.AAA18853@baty.hanse.de>
To:     kuznet@ms2.inr.ac.ru
CC:     riel@conectiva.com.br, davem@redhat.com, netdev@oss.sgi.com
In-reply-to: <200010101501.TAA14198@ms2.inr.ac.ru> (kuznet@ms2.inr.ac.ru)
Subject: Re: BUG in tcp.c ?
References:  <200010101501.TAA14198@ms2.inr.ac.ru>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Hello,


>>>>> "kuznet" == kuznet  <kuznet@ms2.inr.ac.ru> writes:

    kuznet> Sorry? This thing is called O_NONBLOCK. sndtimeo is
    kuznet> additional baroque detail, which is not used provided you
    kuznet> do not touch it. Do not touch it.

Well, I was aware of that. The sndtimeo trick was just a very dirty hack
not intended for final version (and not future-proof;). The reason why
I used it was that by setting sndtimeo to 0, it would make all
sock_alloc_snd_skb() non-blocking, while O_NONBLOCK has to passed as a
parameter and thus might require to consider all sock_alloc_send_skb()
calls in a protocol stack.


    kuznet> What's about calling from interrupts (not the case with
    kuznet> nbd),

If ndb does not call sendmsg from interrupt, sleeping inside sndmsg()
is probably not a problem per se. Is it only the sleep while waiting
for GFP_KERNEL memory allocation which causes the deadlock problems?

    kuznet>       no tricks will help. It is simply impossible to use
    kuznet> top level syscall from interrupt.

Yes -- and for my tunneling scenario, I do not do top level syscalls
from bh context anyway. The sock_alloc_send_skb() which needed to be rendered
non-blocking was used for a fragemt allocation. For this, the sk->allocation
trick was sufficient.

Henner

From owner-netdev@oss.sgi.com Tue Oct 10 16:45:35 2000
Received:  by oss.sgi.com id <S42285AbQJJXpZ>;
	Tue, 10 Oct 2000 16:45:25 -0700
Received: from pizda.ninka.net ([216.101.162.242]:63367 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42273AbQJJXpI>;
	Tue, 10 Oct 2000 16:45:08 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id QAA03979;
	Tue, 10 Oct 2000 16:30:37 -0700
Date:   Tue, 10 Oct 2000 16:30:37 -0700
Message-Id: <200010102330.QAA03979@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     eis@baty.hanse.de
CC:     kuznet@ms2.inr.ac.ru, riel@conectiva.com.br, netdev@oss.sgi.com
In-reply-to: <200010102221.AAA18853@baty.hanse.de> (message from Henner Eisen
	on Wed, 11 Oct 2000 00:21:21 +0200)
Subject: Re: BUG in tcp.c ?
References: <200010101501.TAA14198@ms2.inr.ac.ru> <200010102221.AAA18853@baty.hanse.de>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: Wed, 11 Oct 2000 00:21:21 +0200
   From: Henner Eisen <eis@baty.hanse.de>

   Is it only the sleep while waiting for GFP_KERNEL memory allocation
   which causes the deadlock problems?

To the best of my understanding, yes, this was nbd's problem
precisely.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Tue Oct 10 23:50:49 2000
Received:  by oss.sgi.com id <S42275AbQJKGu3>;
	Tue, 10 Oct 2000 23:50:29 -0700
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:34311 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S42215AbQJKGuB>;
	Tue, 10 Oct 2000 23:50:01 -0700
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.9.3) with ESMTP id AAA20290;
	Wed, 11 Oct 2000 00:41:21 -0700
Message-ID: <39E419A1.DAE3F651@candelatech.com>
Date:   Wed, 11 Oct 2000 00:41:21 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-net <linux-net@vger.rutgers.edu>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: When are net_device names changed/changeable?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

I'm trying to write a hash structure that will hold the devices,
hashed by both name and index.

It seems that the devices are first named generically: eth%d,
and at some later date, are initialized correctly.  This, of course,
completely screws up any name-based hashing I might have had...

If names can change at any time, then I'll just quit trying to
hash on them.  However, if they only change up to some certain
step, then I'll be able to just initialize the hash list after that.

Are the device names (for the devices in dev_base) un-changable after
some point?  What is this point?  (Would 'at-the-first-dev-add' be ok?)

If this is un-workable, I can still hash on ifindex I think, it's
immutable, right?

Thanks,
Ben

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Wed Oct 11 02:32:39 2000
Received:  by oss.sgi.com id <S42291AbQJKJcU>;
	Wed, 11 Oct 2000 02:32:20 -0700
Received: from [192.72.45.189] ([192.72.45.189]:30693 "EHLO
        stsl.siemens.com.tw") by oss.sgi.com with ESMTP id <S42290AbQJKJby>;
	Wed, 11 Oct 2000 02:31:54 -0700
Received: from stslex.siemens.com.tw (stslex [192.72.45.13])
	by stsl.siemens.com.tw (8.9.1/8.9.1) with ESMTP id RAA03328;
	Wed, 11 Oct 2000 17:36:52 +0800 (CST)
Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2448.0)
	id <4QX24B5L>; Wed, 11 Oct 2000 17:21:43 +0800
Message-ID: <C6BEA88DAF6AD31185F500105A835CBB01BAC151@stslex.siemens.com.tw>
From:   Moter Du <Moter_Du@stsl.siemens.com.tw>
To:     linux-net <linux-net@vger.rutgers.edu>, netdev@oss.sgi.com
Subject: RA daemon with MIPv6 extension ?
Date:   Wed, 11 Oct 2000 17:21:41 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C03364.AADE4154"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C03364.AADE4154
Content-Type: text/plain;
	charset="BIG5"

Could someone point out where I can find a Router Advertisement daemon with
MIPv6 extension running over Linux?
Thanks a lot.

> 	Sincerely 
> 	Moter Du
> 
> 	============================================================
> 	Moter Du                                  D410, Siemens STSL
> 	phone	+886 2 25186011
> 	Fax	+886 2 25053866
> 	mailto:moter_du@stsl.siemens.com.tw
		============================================================


------_=_NextPart_001_01C03364.AADE4154
Content-Type: text/html;
	charset="BIG5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DBIG5">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RA daemon with MIPv6 extension ?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Could someone point out where I can find a Router =
Advertisement daemon with MIPv6 extension running over Linux?</FONT>
<BR><FONT SIZE=3D2>Thanks a lot.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sincerely </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Moter Du</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Moter =
Du&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; D410, Siemens =
STSL</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
phone&nbsp;&nbsp; +886 2 25186011</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Fax&nbsp;&nbsp;&nbsp;&nbsp; +886 2 25053866</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"mailto:moter_du@stsl.siemens.com.tw">mailto:moter_du@stsl.siemen=
s.com.tw</A></FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03364.AADE4154--

From owner-netdev@oss.sgi.com Wed Oct 11 03:56:30 2000
Received:  by oss.sgi.com id <S42284AbQJKK4K>;
	Wed, 11 Oct 2000 03:56:10 -0700
Received: from iabgfw.iabg.de ([194.139.245.2]:19183 "EHLO iabgfw.iabg.de")
	by oss.sgi.com with ESMTP id <S42267AbQJKKzs>;
	Wed, 11 Oct 2000 03:55:48 -0700
Received: by iabgfw.iabg.de; id MAA00990; Wed, 11 Oct 2000 12:55:02 +0200 (MET DST)
Received: from iabgmh.iabg.de(10.255.255.2) by iabgfw.iabg.de via smap (V4.2)
	id xma000803; Wed, 11 Oct 00 12:54:52 +0200
Received: from iabgvw.iabg.de ([10.255.255.8]) by iabgmh.iabg.de
          (Post.Office MTA v3.5.1 release 219 ID# 127-59214U1600L300S0V35)
          with ESMTP id de; Wed, 11 Oct 2000 12:54:48 +0200
Received: from iabgdns.iabg.de (localhost [127.0.0.1])
	by iabgvw.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id MAA13719;
	Wed, 11 Oct 2000 12:54:48 +0200 (MET DST)
Received: from iabg.de (cc31pc12.iabg.de [10.3.0.20])
	by iabgdns.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id MAA07828;
	Wed, 11 Oct 2000 12:54:48 +0200 (MET DST)
Message-ID: <39E446F8.F1067515@iabg.de>
Date:   Wed, 11 Oct 2000 12:54:48 +0200
From:   Gerhard Gessler <gessler@iabg.de>
X-Mailer: Mozilla 4.75 [de]C-CCK-MCD DT  (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To:     Moter Du <Moter_Du@stsl.siemens.com.tw>
CC:     linux-net <linux-net@vger.rutgers.edu>, netdev@oss.sgi.com
Subject: Re: RA daemon with MIPv6 extension ?
References: <C6BEA88DAF6AD31185F500105A835CBB01BAC151@stslex.siemens.com.tw>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 676
Lines: 32

> Moter Du schrieb:
> 
> Could someone point out where I can find a Router Advertisement daemon
> with MIPv6 extension running over Linux?
> Thanks a lot.
> 

You might want to look at

http://vesper.tky.hut.fi/mip/

They have a Mobile IPv6 implementation for Linux and ship a modified
version of Lars Fennebergs radvd. I have not taken a closer look, but
from the README file they seem to support the necessary elements for
MIPv6

Regards,

	Gerhard

-- 
---------------------------------------------------
Gerhard Geßler

Communication Networks, IABG mbH
Einsteinstr. 20
85521 Ottobrunn, Germany

Telefon: +49 89 6088 - 2021
Fax: +49 89 6088 - 2845

E-Mail: gessler@iabg.de

From owner-netdev@oss.sgi.com Wed Oct 11 07:32:39 2000
Received:  by oss.sgi.com id <S42293AbQJKOc3>;
	Wed, 11 Oct 2000 07:32:29 -0700
Received: from isis.its.uow.edu.au ([130.130.68.21]:19096 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42278AbQJKOcM>;
	Wed, 11 Oct 2000 07:32:12 -0700
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by isis.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id BAA02207;
	Thu, 12 Oct 2000 01:31:06 +1100 (EST)
Message-ID: <39E47A2B.AE794422@uow.edu.au>
Date:   Thu, 12 Oct 2000 01:33:15 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Ben Greear <greearb@candelatech.com>
CC:     linux-net <linux-net@vger.rutgers.edu>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: When are net_device names changed/changeable?
References: <39E419A1.DAE3F651@candelatech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 878
Lines: 21

Ben Greear wrote:
> 
> I'm trying to write a hash structure that will hold the devices,
> hashed by both name and index.
> 
> It seems that the devices are first named generically: eth%d,
> and at some later date, are initialized correctly.  This, of course,
> completely screws up any name-based hashing I might have had...
> 
> If names can change at any time, then I'll just quit trying to
> hash on them.  However, if they only change up to some certain
> step, then I'll be able to just initialize the hash list after that.
> 
> Are the device names (for the devices in dev_base) un-changable after
> some point?  What is this point?  (Would 'at-the-first-dev-add' be ok?)
> 
> If this is un-workable, I can still hash on ifindex I think, it's
> immutable, right?

Can you not simply add and remove the hashtable entries in
register_netdevice() and unregister_netdevice()?

From owner-netdev@oss.sgi.com Wed Oct 11 08:23:30 2000
Received:  by oss.sgi.com id <S42182AbQJKPXL>;
	Wed, 11 Oct 2000 08:23:11 -0700
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:10255 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S42180AbQJKPWl>;
	Wed, 11 Oct 2000 08:22:41 -0700
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.9.3) with ESMTP id JAA25040;
	Wed, 11 Oct 2000 09:14:01 -0700
Message-ID: <39E491C9.60A55BBA@candelatech.com>
Date:   Wed, 11 Oct 2000 09:14:01 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andrew Morton <andrewm@uow.edu.au>
CC:     linux-net <linux-net@vger.rutgers.edu>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: When are net_device names changed/changeable?
References: <39E419A1.DAE3F651@candelatech.com> <39E47A2B.AE794422@uow.edu.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1753
Lines: 42

Andrew Morton wrote:
> 
> Ben Greear wrote:
> >
> > I'm trying to write a hash structure that will hold the devices,
> > hashed by both name and index.
> >
> > It seems that the devices are first named generically: eth%d,
> > and at some later date, are initialized correctly.  This, of course,
> > completely screws up any name-based hashing I might have had...
> >
> > If names can change at any time, then I'll just quit trying to
> > hash on them.  However, if they only change up to some certain
> > step, then I'll be able to just initialize the hash list after that.
> >
> > Are the device names (for the devices in dev_base) un-changable after
> > some point?  What is this point?  (Would 'at-the-first-dev-add' be ok?)
> >
> > If this is un-workable, I can still hash on ifindex I think, it's
> > immutable, right?
> 
> Can you not simply add and remove the hashtable entries in
> register_netdevice() and unregister_netdevice()?

Yes, but I was worried about devices that exist before anything
is added (loopback dev is what dev_base is initialized to...)

However, I found that if I initialize on the first register_netdevice,
then everything seems to work OK.  The way I wrote the code, if it's
not initialized yet, then it just uses the old way of searching the dev_base
list.

I was able to do an ifconfig -a on a list of 4000 VLAN devices in about 16 seconds
on a Celeron 500, so it does seem to speed things up considerably!!

I should have a cleaned up patch (with VLAN multicast and MAC settability)
available in a few days.

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Wed Oct 11 09:14:01 2000
Received:  by oss.sgi.com id <S42183AbQJKQNv>;
	Wed, 11 Oct 2000 09:13:51 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:14342 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42180AbQJKQNX>;
	Wed, 11 Oct 2000 09:13:23 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA27483; Wed, 11 Oct 2000 20:11:57 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010111611.UAA27483@ms2.inr.ac.ru>
Subject: Re: BUG in tcp.c ?
To:     davem@redhat.com (David S. Miller)
Date:   Wed, 11 Oct 2000 20:11:57 +0400 (MSK DST)
Cc:     eis@baty.hanse.de, riel@conectiva.com.br, netdev@oss.sgi.com
In-Reply-To: <200010102330.QAA03979@pizda.ninka.net> from "David S. Miller" at Oct 10, 0 04:30:37 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1238
Lines: 33

Hello!

>    Is it only the sleep while waiting for GFP_KERNEL memory allocation
>    which causes the deadlock problems?
> 
> To the best of my understanding, yes, this was nbd's problem
> precisely.

I would add that Andi and Marcelo explained me that problem was not
in sleep, but that GFP_KERNEL tries to shrink vm, which results
in additional writes of cached pages, which in turn...
Actually, it is big relief because trick with sk->allocation really helps.

sendmsg, like any syscall, _sleeps_ and it is impossible to override
with either sk->allocation and O_NONBLOCK. And even if it does
not sleep in fact (f.e. in 2.2 or when socket is used exclusively
by single thread in 2.4) it cannot be called with any spinning lock
hold, from bh etc. Only from thread context free of any locks.

BTW this does not apply to sock_alloc_send_skb, it can be called
from any context provided you take precautions about nonblock,
sk->allocation and do not use fallback.

Only... one question:

#define GFP_BUFFER	(__GFP_HIGH | __GFP_WAIT)

Old days GFP_BUFFER did not sleep.
All the sense of fallback allocation was that it grabs large
buffer provided it can make this without stressing memory.
Should GFP_BUFFER be replaced with 0 now?

Alexey

From owner-netdev@oss.sgi.com Wed Oct 11 12:18:01 2000
Received:  by oss.sgi.com id <S42185AbQJKTRl>;
	Wed, 11 Oct 2000 12:17:41 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:62471 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42180AbQJKTRU>;
	Wed, 11 Oct 2000 12:17:20 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA29190; Wed, 11 Oct 2000 23:16:12 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010111916.XAA29190@ms2.inr.ac.ru>
Subject: Re: linux-2.2.17 auto-configuration
To:     jajcus@zeus.polsl.gliwice.PL (Jacek Konieczny)
Date:   Wed, 11 Oct 2000 23:16:12 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20001006192736.A3207@nic.nigdzie> from "Jacek Konieczny" at Oct 9, 0 05:15:01 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 273
Lines: 13

Hello!

> fixing 2.2.x-kernel auto-configuration bug. It seems it was not included
> in 2.2.17 kernel.

It is not included even in 2.4.

I apologize, I remember about this patch. It was good, but not quite correct.
I will sort this as soon as possible.

Thank you!

Alexey

From owner-netdev@oss.sgi.com Wed Oct 11 16:03:51 2000
Received:  by oss.sgi.com id <S42221AbQJKXDm>;
	Wed, 11 Oct 2000 16:03:42 -0700
Received: from natmail2.webmailer.de ([192.67.198.65]:36085 "EHLO
        post.webmailer.de") by oss.sgi.com with ESMTP id <S42214AbQJKXD0>;
	Wed, 11 Oct 2000 16:03:26 -0700
Received: from frog.athome (pec-115-27.tnt7.s2.uunet.de [149.225.115.27])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id BAA04574
	for <netdev@oss.sgi.com>; Thu, 12 Oct 2000 01:02:42 +0200 (MET DST)
Received: from localhost (hgfelger@localhost)
	by frog.athome (8.9.3/8.9.3) with ESMTP id BAA00520
	for <netdev@oss.sgi.com>; Thu, 12 Oct 2000 01:02:30 +0200
X-Authentication-Warning: frog.athome: hgfelger owned process doing -bs
Date:   Thu, 12 Oct 2000 01:02:24 +0200 (CEST)
From:   Hartwig Felger <hgfelger@hgfelger.de>
X-Sender: hgfelger@frog.athome
Reply-To: hgfelger@hgfelger.de
To:     netdev@oss.sgi.com
Subject: ISDN is killing interrupt handler on L2.4.0test9
Message-ID: <Pine.LNX.4.10.10010120059030.517-100000@frog.athome>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1500
Lines: 39

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi folks,
tryed yesterday to dialin to my server at the office (both server and
client are Linux-x86, but server is 2.2.17pre20, whereas the client is
2.4.0test9). As got the wrong nr. first the syncPPP did not work, so I
used an mailbox-like terminal over X75 which worked perfectly. Later I
remebered the right phone-nr. , so I tryed syncPPP also (which is
working on serverside - tryed with other computer...) As the ipppd
started to negotiate the swapper killed the interruphandler.

I found out, that the calltrace included an adress __kfree_skb (+0x34)
and apic_chip_info (+0x942) (I selected CONFIG_X86_UP_IOAPIC) and
isdn_ppp_push_higher (+0x494). After I made a new kernel without
CONFIG_X86_UP_IOAPIC it crashed at nearly the same place, and sayed
Scheduling in interrupt.

Both ways the system was only to be reviewed by the reset-button.

I now tryed it even further, and found out, that if I use a call-by-call
internet-provider, that do not need auth, it does not crash. Linux
test10pre1 did not fix this problem.

Regards hartwig :-(

- -- 
1024D/339FD693 Hartwig Felger <hgfelger@hgfelger.de>
Key fingerprint = FB2F 3EE9 345A D55B 6FF2  0EC1 F5B0 684F 339F D693
For the pulic keys, please visit my page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE55PGG9bBoTzOf1pMRAuRcAJ0VEYj9Gbq/okUwq50NValhJdALwwCeMGmm
BONbhScggMH8DjhJTC5lKLA=
=+7D6
-----END PGP SIGNATURE-----


From owner-netdev@oss.sgi.com Thu Oct 12 08:53:45 2000
Received:  by oss.sgi.com id <S42223AbQJLPxf>;
	Thu, 12 Oct 2000 08:53:35 -0700
Received: from laurin.munich.netsurf.de ([194.64.166.1]:6642 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S42206AbQJLPxL>; Thu, 12 Oct 2000 08:53:11 -0700
Received: from fred.muc.de (noidentity@ns1146.munich.netsurf.de [195.180.235.146])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id RAA23793;
	Thu, 12 Oct 2000 17:52:23 +0200 (MET DST)
Received: by fred.muc.de (Postfix, from userid 500)
	id 9D100E3911; Thu, 12 Oct 2000 03:16:20 +0200 (CEST)
Date:   Thu, 12 Oct 2000 03:16:20 +0200
From:   Andi Kleen <ak@muc.de>
To:     Ben Greear <greearb@candelatech.com>
Cc:     linux-net <linux-net@vger.rutgers.edu>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: When are net_device names changed/changeable?
Message-ID: <20001012031620.A13200@fred.muc.de>
References: <39E419A1.DAE3F651@candelatech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <39E419A1.DAE3F651@candelatech.com>; from greearb@candelatech.com on Wed, Oct 11, 2000 at 08:54:21AM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1099
Lines: 27

On Wed, Oct 11, 2000 at 08:54:21AM +0200, Ben Greear wrote:
> I'm trying to write a hash structure that will hold the devices,
> hashed by both name and index.
> 
> It seems that the devices are first named generically: eth%d,
> and at some later date, are initialized correctly.  This, of course,
> completely screws up any name-based hashing I might have had...
> 
> If names can change at any time, then I'll just quit trying to
> hash on them.  However, if they only change up to some certain
> step, then I'll be able to just initialize the hash list after that.
> 
> Are the device names (for the devices in dev_base) un-changable after
> some point?  What is this point?  (Would 'at-the-first-dev-add' be ok?)

Root can change them anytime using SIOCSIFNAME. I wrote a small program
to rename net devices based on the MAC address, which used it successfully
(so eth0 was always the same adapter, no matter how the modules were loaded)

> 
> If this is un-workable, I can still hash on ifindex I think, it's
> immutable, right?

It is inmutable correct, and easier to hash on anyways.


-Andi

From owner-netdev@oss.sgi.com Thu Oct 12 20:59:19 2000
Received:  by oss.sgi.com id <S553764AbQJMD67>;
	Thu, 12 Oct 2000 20:58:59 -0700
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:46351 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S553757AbQJMD63>;
	Thu, 12 Oct 2000 20:58:29 -0700
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.9.3) with ESMTP id VAA13116;
	Thu, 12 Oct 2000 21:50:48 -0700
Message-ID: <39E694A7.FA4AB35C@candelatech.com>
Date:   Thu, 12 Oct 2000 21:50:47 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andi Kleen <ak@muc.de>
CC:     linux-net <linux-net@vger.rutgers.edu>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: When are net_device names changed/changeable?
References: <39E419A1.DAE3F651@candelatech.com> <20001012031620.A13200@fred.muc.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 2241
Lines: 56

Andi Kleen wrote:
> 
> On Wed, Oct 11, 2000 at 08:54:21AM +0200, Ben Greear wrote:
> > I'm trying to write a hash structure that will hold the devices,
> > hashed by both name and index.
> >
> > It seems that the devices are first named generically: eth%d,
> > and at some later date, are initialized correctly.  This, of course,
> > completely screws up any name-based hashing I might have had...
> >
> > If names can change at any time, then I'll just quit trying to
> > hash on them.  However, if they only change up to some certain
> > step, then I'll be able to just initialize the hash list after that.
> >
> > Are the device names (for the devices in dev_base) un-changable after
> > some point?  What is this point?  (Would 'at-the-first-dev-add' be ok?)
> 
> Root can change them anytime using SIOCSIFNAME. I wrote a small program
> to rename net devices based on the MAC address, which used it successfully
> (so eth0 was always the same adapter, no matter how the modules were loaded)

What if I remove the device from the hash before the name change, and
add it back again after?  That should preserve the hash, and I assume that
the devices will not be renamed regularly, so the slight performance hit
should not be a problem.  I'll probably have to lock the structures
(read/write dev_base), just as the register_netdevice() does...

Do you know of any other ways that the dev name could be changed
after it's added to the list?

> 
> >
> > If this is un-workable, I can still hash on ifindex I think, it's
> > immutable, right?
> 
> It is inmutable correct, and easier to hash on anyways.

Actually, I am currently hashing on both.  I think that speeding up the
search based on name is important too, because if you are binding to an
interface, for example, then you must first map the name into an ifindex.

In other words, binding to each of 4000 interfaces by name could be
quite painful if you're using a linear search each time...

I mean, doesn't everyone need 4k VLAN interfaces?? :)

Thanks,
Ben

> 
> -Andi

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Thu Oct 12 23:48:10 2000
Received:  by oss.sgi.com id <S553762AbQJMGsA>;
	Thu, 12 Oct 2000 23:48:00 -0700
Received: from [192.72.45.189] ([192.72.45.189]:30887 "EHLO
        stsl.siemens.com.tw") by oss.sgi.com with ESMTP id <S553721AbQJMGrf>;
	Thu, 12 Oct 2000 23:47:35 -0700
Received: from stslex.siemens.com.tw (stslex [192.72.45.13])
	by stsl.siemens.com.tw (8.9.1/8.9.1) with ESMTP id OAA13862;
	Fri, 13 Oct 2000 14:54:08 +0800 (CST)
Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2448.0)
	id <4QX24KFR>; Fri, 13 Oct 2000 14:38:56 +0800
Message-ID: <C6BEA88DAF6AD31185F500105A835CBB01BAC15E@stslex.siemens.com.tw>
From:   Moter Du <Moter_Du@stsl.siemens.com.tw>
To:     "'linux-net'" <linux-net@vger.rutgers.edu>,
        "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>
Subject: Cookbook for porting BSD kernel codes to Linux ??
Date:   Fri, 13 Oct 2000 14:38:55 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C034E0.4265BCBA"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1136
Lines: 34

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C034E0.4265BCBA
Content-Type: text/plain;
	charset="BIG5"

I'm about to port some BSD kernel codes, such as IPsec v6 or MIPv6, to Linux
kernel.
Does it exist a cookbook (instructing the porting step by step..) that I may
refer to?
Appreciate any comment and advice.

------_=_NextPart_001_01C034E0.4265BCBA
Content-Type: text/html;
	charset="BIG5"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=BIG5">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0">
<TITLE>Cookbook for porting BSD kernel codes to Linux ??</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I'm about to port some BSD kernel codes, such as IPsec v6 or MIPv6, to Linux kernel.</FONT>
<BR><FONT SIZE=2>Does it exist a cookbook (instructing the porting step by step..) that I may refer to?</FONT>
<BR><FONT SIZE=2>Appreciate any comment and advice.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C034E0.4265BCBA--

From owner-netdev@oss.sgi.com Fri Oct 13 00:08:10 2000
Received:  by oss.sgi.com id <S553767AbQJMHIA>;
	Fri, 13 Oct 2000 00:08:00 -0700
Received: from colin.muc.de ([193.149.48.1]:9733 "HELO colin.muc.de")
	by oss.sgi.com with SMTP id <S553760AbQJMHHs>;
	Fri, 13 Oct 2000 00:07:48 -0700
Received: by colin.muc.de id <140555-1>; Fri, 13 Oct 2000 09:07:30 +0200
Message-ID: <20001013090726.44839@colin.muc.de>
From:   Andi Kleen <ak@muc.de>
To:     Ben Greear <greearb@candelatech.com>
Cc:     Andi Kleen <ak@muc.de>, linux-net <linux-net@vger.rutgers.edu>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: When are net_device names changed/changeable?
References: <39E419A1.DAE3F651@candelatech.com> <20001012031620.A13200@fred.muc.de> <39E694A7.FA4AB35C@candelatech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88e
In-Reply-To: <39E694A7.FA4AB35C@candelatech.com>; from Ben Greear on Fri, Oct 13, 2000 at 06:00:15AM +0200
Date:   Fri, 13 Oct 2000 09:07:27 +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 2543
Lines: 61

On Fri, Oct 13, 2000 at 06:00:15AM +0200, Ben Greear wrote:
> Andi Kleen wrote:
> > 
> > On Wed, Oct 11, 2000 at 08:54:21AM +0200, Ben Greear wrote:
> > > I'm trying to write a hash structure that will hold the devices,
> > > hashed by both name and index.
> > >
> > > It seems that the devices are first named generically: eth%d,
> > > and at some later date, are initialized correctly.  This, of course,
> > > completely screws up any name-based hashing I might have had...
> > >
> > > If names can change at any time, then I'll just quit trying to
> > > hash on them.  However, if they only change up to some certain
> > > step, then I'll be able to just initialize the hash list after that.
> > >
> > > Are the device names (for the devices in dev_base) un-changable after
> > > some point?  What is this point?  (Would 'at-the-first-dev-add' be ok?)
> > 
> > Root can change them anytime using SIOCSIFNAME. I wrote a small program
> > to rename net devices based on the MAC address, which used it successfully
> > (so eth0 was always the same adapter, no matter how the modules were loaded)
> 
> What if I remove the device from the hash before the name change, and
> add it back again after?  That should preserve the hash, and I assume that
> the devices will not be renamed regularly, so the slight performance hit
> should not be a problem.  I'll probably have to lock the structures
> (read/write dev_base), just as the register_netdevice() does...

I am not sure I understand your problem. You probably want two hash
tables, one for the ifindex and one for the ifname. These are separated.
When ifindex or name change you update the appropiate hash table chains under
their lock. 


> Do you know of any other ways that the dev name could be changed
> after it's added to the list?

None.

> 
> > 
> > >
> > > If this is un-workable, I can still hash on ifindex I think, it's
> > > immutable, right?
> > 
> > It is inmutable correct, and easier to hash on anyways.
> 
> Actually, I am currently hashing on both.  I think that speeding up the
> search based on name is important too, because if you are binding to an
> interface, for example, then you must first map the name into an ifindex.
> 
> In other words, binding to each of 4000 interfaces by name could be
> quite painful if you're using a linear search each time...
> 
> I mean, doesn't everyone need 4k VLAN interfaces?? :)

Apparently people do, I recently had to fix a O(n^2) algorithm in ifconfig 
which made printout of thousands of interfaces very slow ... 


-Andi

From owner-netdev@oss.sgi.com Fri Oct 13 00:14:00 2000
Received:  by oss.sgi.com id <S553771AbQJMHNv>;
	Fri, 13 Oct 2000 00:13:51 -0700
Received: from anchor-post-34.mail.demon.net ([194.217.242.92]:61453 "EHLO
        anchor-post-34.mail.demon.net") by oss.sgi.com with ESMTP
	id <S553765AbQJMHNl>; Fri, 13 Oct 2000 00:13:41 -0700
Received: from pnd-pc.demon.co.uk ([158.152.18.190])
	by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1)
	id 13jz2B-000HHE-0Y; Fri, 13 Oct 2000 08:13:40 +0100
Received: from localhost (peterd@localhost)
	by pnd-pc.demon.co.uk (8.9.3/8.9.3) with ESMTP id IAA06673;
	Fri, 13 Oct 2000 08:11:10 +0100
Date:   Fri, 13 Oct 2000 08:11:09 +0100 (BST)
From:   Peter Denison <peterd@pnd-pc.demon.co.uk>
To:     netdev@oss.sgi.com
cc:     linux-net@vger.rutgers.edu
Subject: DEPCA (or DE100) Cards and recent kernels
Message-ID: <Pine.LNX.4.21.0010130753490.3744-100000@pnd-pc.demon.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 600
Lines: 17

I've been hacking on the depca driver recently, in an attempt to get rid
of the ioaddr warnings (properly, by using ioremap etc., rather than
sidestepping the problem). But I can't get it to work....

Can anyone post a success report for getting the standard depca driver to
work on any recent (say 2.4.0-test? ) kernel? I have a feeling some of the
softnet changes a little further back may have broken it.

Grateful for any feedback,
	Peter

-- 
Peter Denison <peterd@pnd-pc.demon.co.uk>
Linux Driver for Promise DC4030VL cards.
See http://www.pnd-pc.demon.co.uk/promise/promise.html for details



From owner-netdev@oss.sgi.com Fri Oct 13 00:51:30 2000
Received:  by oss.sgi.com id <S553770AbQJMHvU>;
	Fri, 13 Oct 2000 00:51:20 -0700
Received: from mail.informatik.uni-ulm.de ([134.60.68.63]:21618 "EHLO
        mail.informatik.uni-ulm.de") by oss.sgi.com with ESMTP
	id <S553765AbQJMHvG>; Fri, 13 Oct 2000 00:51:06 -0700
Received: from [134.60.8.230] (helo=ferret.extern.uni-ulm.de ident=user90792)
	by mail.informatik.uni-ulm.de with esmtp (Exim 3.00 #1)
	id 13jzci-00026q-00
	for netdev@oss.sgi.com; Fri, 13 Oct 2000 09:51:25 +0200
Received: from blackbird.extern.uni-ulm.de ([172.16.1.10])
	by ferret.extern.uni-ulm.de with esmtp (Exim 3.02 #2)
	id 13jzYT-000048-00
	for netdev@oss.sgi.com; Fri, 13 Oct 2000 09:47:01 +0200
Received: (from stefan@localhost)
	by blackbird.extern.uni-ulm.de (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) id e9D7kka01329
	for netdev@oss.sgi.com; Fri, 13 Oct 2000 09:46:46 +0200
Date:   Fri, 13 Oct 2000 09:46:46 +0200
From:   Stefan Schlott <stefan.schlott@student.uni-ulm.de>
To:     Linux Netdev <netdev@oss.sgi.com>
Subject: Modifying sk_buff in ip6_xmit
Message-ID: <20001013094646.A948@blackbird.extern.uni-ulm.de>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1290
Lines: 30

Hi all,

I'm trying to modify the data passed to ip6_xmit (in ip6_output.c)...
The new data will be a bit larger, so I use skb_push to increase the data
size in skb (after making sure that there is enough headroom for both
my data and all extension headers):
  skb->h.raw = skb_push(skb,required_size);
This works perfectly fine... until I update the payload size (which will
be inserted in the IPv6 header later):
  seg_len += required_size;
If I update seg_len, my computer freezes (no oops, no kernel panic).
If I don't update it, I will (of course) get truncated packets.

The point that drives me insane is that everything works fine when
inserting extension headers!

I'm working with kernel ver. 2.4.0-test9. My network tests use the lo
loopback device.

Anyone any ideas? Any help would be really appreciated...

Stefan.

-- 
*--- please cut here... -------------------------------------- thanks! ---*
|-> E-Mail: stefan.schlott@student.uni-ulm.de    DH-PGP-Key: 0x2F36F4FE <-|
| If Bill Gates had a dime for every time a Windows box crashed... oh,    |
| wait a minute -- he already does.                                       |
|   -- Seen on Slashdot (19.04.2000)                                      |
*-------------------------------------------------------------------------*

From owner-netdev@oss.sgi.com Fri Oct 13 04:35:32 2000
Received:  by oss.sgi.com id <S553761AbQJMLfM>;
	Fri, 13 Oct 2000 04:35:12 -0700
Received: from tml.hut.fi ([130.233.44.1]:25615 "EHLO tml-gw.tml.hut.fi")
	by oss.sgi.com with ESMTP id <S553678AbQJMLey>;
	Fri, 13 Oct 2000 04:34:54 -0700
Received: (from smap@localhost)
	by tml-gw.tml.hut.fi (8.8.7/8.8.7) id OAA27699
	for <netdev@oss.sgi.com>; Fri, 13 Oct 2000 14:34:52 +0300
Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0)
	id xma027693; Fri, 13 Oct 00 14:34:50 +0300
Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7])
	by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id e9DBYkM23099;
	Fri, 13 Oct 2000 14:34:46 +0300 (EEST)
Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id OAA27476; Fri, 13 Oct 2000 14:34:26 +0300 (EET DST)
X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs
Date:   Fri, 13 Oct 2000 14:34:26 +0300 (EET DST)
From:   Lars Henrik Petander <lpetande@tml.hut.fi>
To:     Moter Du <Moter_Du@stsl.siemens.com.tw>
cc:     linux-net <linux-net@vger.rutgers.edu>, netdev@oss.sgi.com
Subject: Re: RA daemon with MIPv6 extension ?
In-Reply-To: <C6BEA88DAF6AD31185F500105A835CBB01BAC151@stslex.siemens.com.tw>
Message-ID: <Pine.SOL.4.10.10010131428430.26928-100000@morphine.tml.hut.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 831
Lines: 30



On Wed, 11 Oct 2000, Moter Du wrote:

> Could someone point out where I can find a Router Advertisement daemon with
> MIPv6 extension running over Linux?
> Thanks a lot.

The GO project at Helsinki University of Technology is currently working
on MIPv6 for Linux. We have modified Lars Fennenberg's radvd to support
MIPv6 extensions. In the beginning of November we'll make a new release
which will include the modified radvd. Check out
http://www.mipl.mediapoli.com

Regards,
Henrik Petander

> 
> > 	Sincerely 
> > 	Moter Du
> > 
> > 	============================================================
> > 	Moter Du                                  D410, Siemens STSL
> > 	phone	+886 2 25186011
> > 	Fax	+886 2 25053866
> > 	mailto:moter_du@stsl.siemens.com.tw
> 		============================================================
> 
> 


From owner-netdev@oss.sgi.com Fri Oct 13 08:22:42 2000
Received:  by oss.sgi.com id <S553778AbQJMPWc>;
	Fri, 13 Oct 2000 08:22:32 -0700
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:38410 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S553775AbQJMPWa>;
	Fri, 13 Oct 2000 08:22:30 -0700
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.9.3) with ESMTP id JAA18757;
	Fri, 13 Oct 2000 09:14:54 -0700
Message-ID: <39E734FD.D25DF589@candelatech.com>
Date:   Fri, 13 Oct 2000 09:14:53 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andi Kleen <ak@muc.de>
CC:     linux-net <linux-net@vger.rutgers.edu>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: When are net_device names changed/changeable?
References: <39E419A1.DAE3F651@candelatech.com> <20001012031620.A13200@fred.muc.de> <39E694A7.FA4AB35C@candelatech.com> <20001013090726.44839@colin.muc.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 3040
Lines: 61

Andi Kleen wrote:
> 
> On Fri, Oct 13, 2000 at 06:00:15AM +0200, Ben Greear wrote:
> > Andi Kleen wrote:
> > >
> > > On Wed, Oct 11, 2000 at 08:54:21AM +0200, Ben Greear wrote:
> > > > I'm trying to write a hash structure that will hold the devices,
> > > > hashed by both name and index.
> > > >
> > > > It seems that the devices are first named generically: eth%d,
> > > > and at some later date, are initialized correctly.  This, of course,
> > > > completely screws up any name-based hashing I might have had...
> > > >
> > > > If names can change at any time, then I'll just quit trying to
> > > > hash on them.  However, if they only change up to some certain
> > > > step, then I'll be able to just initialize the hash list after that.
> > > >
> > > > Are the device names (for the devices in dev_base) un-changable after
> > > > some point?  What is this point?  (Would 'at-the-first-dev-add' be ok?)
> > >
> > > Root can change them anytime using SIOCSIFNAME. I wrote a small program
> > > to rename net devices based on the MAC address, which used it successfully
> > > (so eth0 was always the same adapter, no matter how the modules were loaded)
> >
> > What if I remove the device from the hash before the name change, and
> > add it back again after?  That should preserve the hash, and I assume that
> > the devices will not be renamed regularly, so the slight performance hit
> > should not be a problem.  I'll probably have to lock the structures
> > (read/write dev_base), just as the register_netdevice() does...
> 
> I am not sure I understand your problem. You probably want two hash
> tables, one for the ifindex and one for the ifname. These are separated.
> When ifindex or name change you update the appropiate hash table chains under
> their lock.

I have two tables, but was told that ifindex cannot change, so don't have to
worry about that one...

I didn't want to add an extra lock because I don't expect ppl to be re-naming
devices too often, and right now, the code that needs locking is already
protected by the already-existing dev_base locks.  I figure that having one
slightly coarser lock around rarely used code (change_name(..)) was preferable to adding another
lock around more often-run code (the dev_get_**).  I'll separate out the patch
from my VLAN code and post it for examinations this weekend..when it's written :)

> > I mean, doesn't everyone need 4k VLAN interfaces?? :)
> 
> Apparently people do, I recently had to fix a O(n^2) algorithm in ifconfig
> which made printout of thousands of interfaces very slow ...

I noticed that my hack brought an ifconfig -a of 1000 devices from about 7 seconds
to about 1 second on my Celeron 500.  However, I think I might still be using an n^2
algorithm ifconfig, because it became about 20 seconds on 4k devices (with my patch.)

> 
> -Andi

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Fri Oct 13 08:58:01 2000
Received:  by oss.sgi.com id <S553786AbQJMP5v>;
	Fri, 13 Oct 2000 08:57:51 -0700
Received: from perninha.conectiva.com.br ([200.250.58.156]:2830 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553783AbQJMP5m>; Fri, 13 Oct 2000 08:57:42 -0700
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id NAA13974;
	Fri, 13 Oct 2000 13:53:19 -0200
Date:   Fri, 13 Oct 2000 13:54:38 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     kuznet@ms2.inr.ac.ru
cc:     "David S. Miller" <davem@redhat.com>, eis@baty.hanse.de,
        riel@conectiva.com.br, netdev@oss.sgi.com
Subject: Re: BUG in tcp.c ?
In-Reply-To: <200010111611.UAA27483@ms2.inr.ac.ru>
Message-ID: <Pine.LNX.4.21.0010131337430.5155-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1993
Lines: 56



On Wed, 11 Oct 2000 kuznet@ms2.inr.ac.ru wrote:

> Hello!
> 
> >    Is it only the sleep while waiting for GFP_KERNEL memory allocation
> >    which causes the deadlock problems?
> > 
> > To the best of my understanding, yes, this was nbd's problem
> > precisely.
> 
> I would add that Andi and Marcelo explained me that problem was not
> in sleep, but that GFP_KERNEL tries to shrink vm, which results
> in additional writes of cached pages, which in turn...
> Actually, it is big relief because trick with sk->allocation really helps.
> 
> sendmsg, like any syscall, _sleeps_ and it is impossible to override
> with either sk->allocation and O_NONBLOCK. And even if it does
> not sleep in fact (f.e. in 2.2 or when socket is used exclusively
> by single thread in 2.4) it cannot be called with any spinning lock
> hold, from bh etc. Only from thread context free of any locks.
> 
> BTW this does not apply to sock_alloc_send_skb, it can be called
> from any context provided you take precautions about nonblock,
> sk->allocation and do not use fallback.
> 
> Only... one question:
> 
> #define GFP_BUFFER	(__GFP_HIGH | __GFP_WAIT)
> 
> Old days GFP_BUFFER did not sleep.
> All the sense of fallback allocation was that it grabs large
> buffer provided it can make this without stressing memory.
> Should GFP_BUFFER be replaced with 0 now?

Reading core/sock.c (kernel 2.2), I've found: (sock_alloc_skb function) 
 
	if (fallback) {
                        /* The buffer get won't block, or use the atomic  queue.
                         * It does produce annoying no free page messages still.
                         */
                        skb = sock_wmalloc(sk, size, 0, GFP_BUFFER);
                        if (skb)
                                break;
                        try_size = fallback;
                }


If I understood correctly, the code relies on that GFP_BUFFER allocations
will not sleep, right ? 

If so, there is a problem, because GFP_BUFFER may sleep. 




From owner-netdev@oss.sgi.com Fri Oct 13 09:09:11 2000
Received:  by oss.sgi.com id <S553790AbQJMQJC>;
	Fri, 13 Oct 2000 09:09:02 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:30479 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553787AbQJMQJB>;
	Fri, 13 Oct 2000 09:09:01 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA30191; Fri, 13 Oct 2000 20:08:23 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010131608.UAA30191@ms2.inr.ac.ru>
Subject: Re: BUG in tcp.c ?
To:     marcelo@conectiva.com.br (Marcelo Tosatti)
Date:   Fri, 13 Oct 2000 20:08:23 +0400 (MSK DST)
Cc:     davem@redhat.com, eis@baty.hanse.de, riel@conectiva.com.br,
        netdev@oss.sgi.com
In-Reply-To: <Pine.LNX.4.21.0010131337430.5155-100000@freak.distro.conectiva> from "Marcelo Tosatti" at Oct 13, 0 01:54:38 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 521
Lines: 17

Hello!

> If I understood correctly, the code relies on that GFP_BUFFER allocations
> will not sleep, right ? 

No, really. This branch is used exactly from one place and
we may sleep there.

I am afraid not of this, but that it is too agressive.
The idea was to get high order chunk of memory (32K as rule),
if memory is not under pressure. And if it is a problem,
allocate small page sized buffer using sk->allocation.

This code is very old. I suspect it is not valid now.
Maybe it should use GFP_NULL = 0. 8)

Alexey

From owner-netdev@oss.sgi.com Fri Oct 13 15:31:25 2000
Received:  by oss.sgi.com id <S553811AbQJMWbP>;
	Fri, 13 Oct 2000 15:31:15 -0700
Received: from mta13-acc.tin.it ([212.216.176.44]:60659 "EHLO fep13-svc.tin.it")
	by oss.sgi.com with ESMTP id <S553808AbQJMWbA>;
	Fri, 13 Oct 2000 15:31:00 -0700
Received: from armageddon.allanon.org ([212.216.2.47]) by fep13-svc.tin.it
          (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP
          id <20001013223053.JCAD15796.fep13-svc.tin.it@armageddon.allanon.org>
          for <netdev@oss.sgi.com>; Sat, 14 Oct 2000 00:30:53 +0200
Received: by armageddon.allanon.org (Postfix, from userid 0)
	id 0CDB26000; Sat, 14 Oct 2000 00:30:45 +0200 (CEST)
Date:   Sat, 14 Oct 2000 00:09:26 +0200
From:   Gigi Sullivan <sullivan@sikurezza.org>
To:     netdev@oss.sgi.com
Subject: Information about scm_cookie{}
Message-ID: <20001014000926.A1911@armageddon.tin.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.5i
X-Mailer: Mutt 0.95.5i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 743
Lines: 29

Aiee :)

   Hello!

   While trying to follow the routines involved when sending
   an inet packet, I found calls to scm_send which
   use scm_cookie struct.

   Can someone point me out the means and the use of such
   struct and call? (documentations/url/whatsoever are really
   welcome as well ;))

Thx a lot && bye bye

                  -- gg sullivan

P.S.

I had trouble to send this msg to linux-net@vger.rutgers.edu
reason: user unknown - Is everything right?

-- 
Lorenzo Cavallaro	`Gigi Sullivan' <sullivan@sikurezza.org>

LibRNet Project Home Page: http://www.sikurezza.org/sullivan
LibRNet Mailing List: librnet-subscribe@egroups.com

Until I loved, life had no beauty;
I did not know I lived until I had loved. (Theodor Korner)

From owner-netdev@oss.sgi.com Sat Oct 14 09:00:24 2000
Received:  by oss.sgi.com id <S553832AbQJNQAO>;
	Sat, 14 Oct 2000 09:00:14 -0700
Received: from 3dyn17.com21.casema.net ([212.64.94.17]:3597 "HELO home.ds9a.nl")
	by oss.sgi.com with SMTP id <S553815AbQJNP7x>;
	Sat, 14 Oct 2000 08:59:53 -0700
Received: (qmail 8301 invoked by uid 500); 14 Oct 2000 16:54:19 -0000
Date:   Sat, 14 Oct 2000 18:54:19 +0200
From:   bert hubert <ahu@ds9a.nl>
To:     netdev@oss.sgi.com
Subject: packet reordering
Message-ID: <20001014185419.A8295@home.ds9a.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre4i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1687
Lines: 49

Hi everybody,

In the course of working on the Linux Advanced Routing & Shaping HOWTO
(http://ds9a.nl/2.4Routing), I discovered something, which lead me to
writing this:

++++

 Caveats

 (...)

 FIXME: the packet reordering bit needs to be verified by an expert 

 Then there is the nasty problem of packet reordering. Let's say 6 packets
 need to be sent from A to B - eth1 might get 1, 3 and 5. eth2 would then do
 2, 4 and 6. In an ideal world, router B would receive this in order, 1, 2,
 3, 4, 5, 6. But the possibility is very real that the kernel gets it like
 this: 2, 1, 4, 3, 6, 5. The problem is that this confuses TCP/IP. While not
 a problem for links carrying many different TCP/IP sessions, you won't be
 able to to a bundle multiple links and get to ftp a single file lots
 faster.

 However, for lots of applications, link loadbalancing is a great idea. 

++++

Firstly, you are the mentioned 'experts', so please comment about my
explanation. Secondly, I was wondering if it would be possible to easily
make an ingress 'policer' that creates some latency, but does order TCP
packets on sequence number within that latency.

Would such a beast be possible? If you think it would be worthwile, I'll try
to code it.

Thirdly, I tried the normal ingress policer with the script as provided by
Alexey, but it gave me an error:

# tc qdisc add dev eth0 handle ffff: ingress
RTNETLINK answers: No such file or directory

I think I included everything needed in the kernel.

Thanks for your attention.

-- 
PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

From owner-netdev@oss.sgi.com Sat Oct 14 21:34:23 2000
Received:  by oss.sgi.com id <S553863AbQJOEeO>;
	Sat, 14 Oct 2000 21:34:14 -0700
Received: from [216.161.55.93] ([216.161.55.93]:13039 "EHLO blue.int.wirex.com")
	by oss.sgi.com with ESMTP id <S553860AbQJOEd7>;
	Sat, 14 Oct 2000 21:33:59 -0700
Received: (from greg@localhost)
	by blue.int.wirex.com (8.9.3/8.9.3) id VAA02016;
	Sat, 14 Oct 2000 21:39:04 -0700
Date:   Sat, 14 Oct 2000 21:39:04 -0700
From:   Greg KH <greg@wirex.com>
To:     Gigi Sullivan <sullivan@sikurezza.org>
Cc:     netdev@oss.sgi.com
Subject: Re: Information about scm_cookie{}
Message-ID: <20001014213904.A1764@wirex.com>
References: <20001014000926.A1911@armageddon.tin.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001014000926.A1911@armageddon.tin.it>; from sullivan@sikurezza.org on Sat, Oct 14, 2000 at 12:09:26AM +0200
X-Operating-System: Linux 2.2.17-immunix (i686)
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 370
Lines: 12

On Sat, Oct 14, 2000 at 12:09:26AM +0200, Gigi Sullivan wrote:
> I had trouble to send this msg to linux-net@vger.rutgers.edu
> reason: user unknown - Is everything right?

You might try linux-net@vger.kernel.org, as vger.rutgers.edu is no
longer around, and all of the lists were moved to vger.kernel.org.

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg

From owner-netdev@oss.sgi.com Sun Oct 15 01:56:04 2000
Received:  by oss.sgi.com id <S553864AbQJOIzy>;
	Sun, 15 Oct 2000 01:55:54 -0700
Received: from kogge.hanse.de ([192.76.134.17]:58384 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553690AbQJOIzl>;
	Sun, 15 Oct 2000 01:55:41 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id LAA71796;
	Sun, 15 Oct 2000 11:00:10 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id VAA10414;
	Fri, 13 Oct 2000 21:24:12 +0200
To:     hgfelger@hgfelger.de
cc:     netdev@oss.sgi.com
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
References: <Pine.LNX.4.10.10010120059030.517-100000@frog.athome>
From:   Henner Eisen <eis@baty.hanse.de>
Date:   13 Oct 2000 21:24:11 +0200
In-Reply-To: Hartwig Felger's message of "Thu, 12 Oct 2000 01:02:24 +0200 (CEST)"
Message-ID: <oug0m0ilyc.fsf@baty.hanse.de>
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 506
Lines: 16


Hi,

>>>>> "Hartwig" == Hartwig Felger <hgfelger@hgfelger.de> writes:

    Hartwig> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

    Hartwig> Hi folks, tryed yesterday to dialin to my server at the
    Hartwig> office (both server and client are Linux-x86, but server
    Hartwig> is 2.2.17pre20, whereas the client is 2.4.0test9). As got

Did you use an actual version of the isdn4k-utils compiled against
2.4.0-test9 header files? If not, isdnctrl or ipppd should give you a
warning messages.

Henner

From owner-netdev@oss.sgi.com Sun Oct 15 07:22:49 2000
Received:  by oss.sgi.com id <S553750AbQJOOWj>;
	Sun, 15 Oct 2000 07:22:39 -0700
Received: from anchor-post-34.mail.demon.net ([194.217.242.92]:46608 "EHLO
        anchor-post-34.mail.demon.net") by oss.sgi.com with ESMTP
	id <S553709AbQJOOWS>; Sun, 15 Oct 2000 07:22:18 -0700
Received: from pnd-pc.demon.co.uk ([158.152.18.190])
	by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1)
	id 13kofy-000AuF-0Y; Sun, 15 Oct 2000 15:22:11 +0100
Received: from localhost (peterd@localhost)
	by pnd-pc.demon.co.uk (8.9.3/8.9.3) with ESMTP id WAA01176;
	Sat, 14 Oct 2000 22:16:05 +0100
Date:   Sat, 14 Oct 2000 22:16:05 +0100 (BST)
From:   Peter Denison <peterd@pnd-pc.demon.co.uk>
To:     netdev@oss.sgi.com
cc:     davies@maniac.ultranet.com, Chris Carr <chrisc@dbass.demon.co.uk>
Subject: DEPCA driver and kernels > 2.3.43
Message-ID: <Pine.LNX.4.21.0010142214300.1013-200000@pnd-pc.demon.co.uk>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1734427118-1221937577-971558165=:1013"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 35091
Lines: 600

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---1734427118-1221937577-971558165=:1013
Content-Type: TEXT/PLAIN; charset=US-ASCII

Obviously nobody uses the DEPCA driver any more! It's been
(seriously) broken since the softnet changes went in in the 2.3.44
patch. At the end of the interrupt routine, the interrupts are only
unmasked if the queue is stopped!

This patch fixes it:

--- drivers/net/depca.c.old	Sun Jul 30 17:24:13 2000
+++ drivers/net/depca.c	Sat Oct 14 20:58:08 2000
@@ -908,12 +925,12 @@
 	/* Any resources available? */
 	if ((TX_BUFFS_AVAIL >= 0) && netif_queue_stopped(dev)) {
 		netif_wake_queue (dev);
-
-		/* Unmask the DEPCA board interrupts and turn off the LED */
-		nicsr = (nicsr & ~IM & ~LED);
-		outb (nicsr, DEPCA_NICSR);
 	}
 
+	/* Unmask the DEPCA board interrupts and turn off the LED */
+	nicsr = (nicsr & ~IM & ~LED);
+	outb (nicsr, DEPCA_NICSR);
+
 	spin_unlock (&lp->lock);
 }

I've also attached a larger (considerably larger) patch against
2.4.0-test9 which redoes all the memory accesses in terms of properly
ioremapped addresses, removing all the warnings.

If I don't hear anything within a few days from anyone here, I'll post the
patches off to Linus.

-- 
Peter Denison <peterd@pnd-pc.demon.co.uk>
Linux Driver for Promise DC4030VL cards.
See http://www.pnd-pc.demon.co.uk/promise/promise.html for details



---1734427118-1221937577-971558165=:1013
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="2.4.0-test9-depca"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0010142216050.1013@pnd-pc.demon.co.uk>
Content-Description: DEPCA isa memory patch
Content-Disposition: attachment; filename="2.4.0-test9-depca"

LS0tIGRyaXZlcnMvbmV0L2RlcGNhLmMub2xkCVN1biBKdWwgMzAgMTc6MjQ6
MTMgMjAwMA0KKysrIGRyaXZlcnMvbmV0L2RlcGNhLmMJU2F0IE9jdCAxNCAy
MDo1ODowOCAyMDAwDQpAQCAtMjIzLDYgKzIyMyw3IEBADQogICAgICAgMC41
ICAgICAxNC1Ob3YtOTggICBSZS1zcGluIGZvciAyLjEueCBrZXJuZWxzLg0K
ICAgICAgIDAuNTEgICAgMjctSnVuLTk5ICAgQ29ycmVjdCByZWNlaXZlZCBw
YWNrZXQgbGVuZ3RoIGZvciBDUkMgZnJvbQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHJlcG9ydCBieSA8d29ybUBka2lrLmRrPg0KKyAgICAgIDAu
NTIgICAgMTQtTWF5LTAwICAgRml4ZXMgZm9yIDIuMyBpbyBtZW1vcnkgYWNj
ZXNzZXMgPHBldGVyZEBwbmQtcGMuZGVtb24uY28udWs+DQogDQogICAgID09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiAqLw0KQEAgLTM3OCwxNCAr
Mzc5LDIxIEBADQogICAgIGNoYXIgZGV2bmFtZVtERVBDQV9TVFJMRU5dOyAg
ICAvKiBEZXZpY2UgUHJvZHVjdCBTdHJpbmcgICAgICAgICAgICAgICAgICAq
Lw0KICAgICBjaGFyIGFkYXB0ZXJfbmFtZVtERVBDQV9TVFJMRU5dOy8qIC9w
cm9jL2lvcG9ydHMgc3RyaW5nICAgICAgICAgICAgICAgICAgKi8NCiAgICAg
Y2hhciBhZGFwdGVyOyAgICAgICAgICAgICAgICAgIC8qIEFkYXB0ZXIgdHlw
ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICovDQotICAgIGNoYXIgbWNh
X3Nsb3Q7ICAgICAgICAgICAgICAgICAvKiBNQ0Egc2xvdCwgaWYgTUNBIGVs
c2UgLTEgICAgICAgICAgICAgICAqLyAgICBzdHJ1Y3QgZGVwY2FfcnhfZGVz
YyAqcnhfcmluZzsgLyogUG9pbnRlciB0byBzdGFydCBvZiBSWCBkZXNjcmlw
dG9yIHJpbmcgKi8NCi0gICAgc3RydWN0IGRlcGNhX3R4X2Rlc2MgKnR4X3Jp
bmc7IC8qIFBvaW50ZXIgdG8gc3RhcnQgb2YgVFggZGVzY3JpcHRvciByaW5n
ICovDQorICAgIGNoYXIgbWNhX3Nsb3Q7ICAgICAgICAgICAgICAgICAvKiBN
Q0Egc2xvdCwgaWYgTUNBIGVsc2UgLTEgICAgICAgICAgICAgICAqLw0KICAg
ICBzdHJ1Y3QgZGVwY2FfaW5pdAlpbml0X2Jsb2NrOy8qIFNoYWRvdyBJbml0
aWFsaXphdGlvbiBibG9jayAgICAgICAgICAgICovDQotICAgIGNoYXIgKnJ4
X21lbWNweVtOVU1fUlhfREVTQ107ICAvKiBDUFUgdmlydCBhZGRyZXNzIG9m
IHNoJ2QgbWVtb3J5IGJ1ZmZzICAqLw0KLSAgICBjaGFyICp0eF9tZW1jcHlb
TlVNX1RYX0RFU0NdOyAgLyogQ1BVIHZpcnQgYWRkcmVzcyBvZiBzaCdkIG1l
bW9yeSBidWZmcyAgKi8NCi0gICAgdV9sb25nIGJ1c19vZmZzZXQ7ICAgICAg
ICAgICAgIC8qIChFKUlTQSBidXMgYWRkcmVzcyBvZmZzZXQgdnMgTEFOQ0Ug
ICAgICovDQotICAgIHVfbG9uZyBzaF9tZW07ICAJCSAgIC8qIFBoeXNpY2Fs
IHN0YXJ0IGFkZHIgb2Ygc2hhcmVkIG1lbSBhcmVhICovDQotICAgIHVfbG9u
ZyBkbWFfYnVmZnM7CQkgICAvKiBMQU5DRSBSeCBhbmQgVHggYnVmZmVycyBz
dGFydCBhZGRyZXNzLiAqLw0KKy8qIENQVSBhZGRyZXNzIHNwYWNlIGZpZWxk
cyAqLw0KKyAgICBzdHJ1Y3QgZGVwY2FfcnhfZGVzYyAqcnhfcmluZzsgLyog
UG9pbnRlciB0byBzdGFydCBvZiBSWCBkZXNjcmlwdG9yIHJpbmcgKi8NCisg
ICAgc3RydWN0IGRlcGNhX3R4X2Rlc2MgKnR4X3Jpbmc7IC8qIFBvaW50ZXIg
dG8gc3RhcnQgb2YgVFggZGVzY3JpcHRvciByaW5nICovDQorICAgIHZvaWQg
KnJ4X2J1ZmZbTlVNX1JYX0RFU0NdOyAgICAvKiBDUFUgdmlydCBhZGRyZXNz
IG9mIHNoJ2QgbWVtb3J5IGJ1ZmZzICAqLw0KKyAgICB2b2lkICp0eF9idWZm
W05VTV9UWF9ERVNDXTsgICAgLyogQ1BVIHZpcnQgYWRkcmVzcyBvZiBzaCdk
IG1lbW9yeSBidWZmcyAgKi8NCisgICAgdm9pZCAqc2hfbWVtOyAgICAgICAg
ICAgICAgICAgIC8qIENQVSBtYXBwZWQgdmlydCBhZGRyZXNzIG9mIGRldmlj
ZSBSQU0gICovDQorLyogRGV2aWNlIGFkZHJlc3Mgc3BhY2UgZmllbGRzICov
DQorICAgIHVfbG9uZyBkZXZpY2VfcmFtX3N0YXJ0OyAgICAgICAvKiBTdGFy
dCBvZiBSQU0gaW4gZGV2aWNlIGFkZHIgc3BhY2UgICAgICAqLw0KKy8qIE9m
ZnNldHMgdXNlZCBpbiBib3RoIGFkZHJlc3Mgc3BhY2VzICovDQorICAgIHVf
bG9uZyByeF9yaW5nX29mZnNldDsgICAgICAgICAvKiBPZmZzZXQgZnJvbSBz
dGFydCBvZiBSQU0gdG8gcnhfcmluZyAgICAqLw0KKyAgICB1X2xvbmcgdHhf
cmluZ19vZmZzZXQ7ICAgICAgICAgLyogT2Zmc2V0IGZyb20gc3RhcnQgb2Yg
UkFNIHRvIHR4X3JpbmcgICAgKi8NCisgICAgdV9sb25nIGJ1ZmZzX29mZnNl
dDsJICAgLyogTEFOQ0UgUnggYW5kIFR4IGJ1ZmZlcnMgc3RhcnQgYWRkcmVz
cy4gKi8NCisvKiBLZXJuZWwtb25seSAobm90IGRldmljZSkgZmllbGRzICov
DQogICAgIGludAlyeF9uZXcsIHR4X25ldzsJCSAgIC8qIFRoZSBuZXh0IGZy
ZWUgcmluZyBlbnRyeSAgICAgICAgICAgICAgICovDQogICAgIGludCByeF9v
bGQsIHR4X29sZDsJICAgICAgICAgICAvKiBUaGUgcmluZyBlbnRyaWVzIHRv
IGJlIGZyZWUoKWVkLiAgICAgICAqLw0KICAgICBzdHJ1Y3QgbmV0X2Rldmlj
ZV9zdGF0cyBzdGF0czsNCkBAIC01MTcsMjE1ICs1MjUsMjIwIEBADQogc3Rh
dGljIGludCBfX2luaXQgDQogZGVwY2FfaHdfaW5pdChzdHJ1Y3QgbmV0X2Rl
dmljZSAqZGV2LCB1X2xvbmcgaW9hZGRyLCBpbnQgbWNhX3Nsb3QpDQogew0K
LSAgc3RydWN0IGRlcGNhX3ByaXZhdGUgKmxwOw0KLSAgaW50IGksIGosIG9m
ZnNldCwgbmV0UkFNLCBtZW1fbGVuLCBzdGF0dXM9MDsNCi0gIHMxNiBuaWNz
cjsNCi0gIHVfbG9uZyBtZW1fc3RhcnQ9MCwgbWVtX2Jhc2VbXSA9IERFUENB
X1JBTV9CQVNFX0FERFJFU1NFUzsNCisJc3RydWN0IGRlcGNhX3ByaXZhdGUg
KmxwOw0KKwlpbnQgaSwgaiwgb2Zmc2V0LCBuZXRSQU0sIG1lbV9sZW4sIHN0
YXR1cz0wOw0KKwlzMTYgbmljc3I7DQorCXVfbG9uZyBtZW1fc3RhcnQ9MCwg
bWVtX2Jhc2VbXSA9IERFUENBX1JBTV9CQVNFX0FERFJFU1NFUzsNCiANCi0g
IFNUT1BfREVQQ0E7DQorCVNUT1BfREVQQ0E7DQogDQotICBuaWNzciA9IGlu
YihERVBDQV9OSUNTUik7DQotICBuaWNzciA9ICgobmljc3IgJiB+U0hFICYg
flJCRSAmIH5JRU4pIHwgSU0pOw0KLSAgb3V0YihuaWNzciwgREVQQ0FfTklD
U1IpOw0KKwluaWNzciA9IGluYihERVBDQV9OSUNTUik7DQorCW5pY3NyID0g
KChuaWNzciAmIH5TSEUgJiB+UkJFICYgfklFTikgfCBJTSk7DQorCW91dGIo
bmljc3IsIERFUENBX05JQ1NSKTsNCiANCi0gIGlmIChpbncoREVQQ0FfREFU
QSkgPT0gU1RPUCkgew0KLSAgICBkbyB7DQotICAgICAgc3RyY3B5KG5hbWUs
IChhZGFwdGVyX25hbWUgPyBhZGFwdGVyX25hbWUgOiAiIikpOw0KLSAgICAg
IG1lbV9zdGFydCA9IChtZW0gPyBtZW0gJiAweGYwMDAwIDogbWVtX2Jhc2Vb
bWVtX2Noa2QrK10pOw0KLSAgICAgIERlcGNhU2lnbmF0dXJlKG5hbWUsIG1l
bV9zdGFydCk7DQotICAgIH0gd2hpbGUgKCFtZW0gJiYgbWVtX2Jhc2VbbWVt
X2Noa2RdICYmIChhZGFwdGVyID09IHVua25vd24pKTsNCi0NCi0gICAgaWYg
KChhZGFwdGVyICE9IHVua25vd24pICYmIG1lbV9zdGFydCkgeyAgICAgICAg
LyogZm91bmQgYSBERVBDQSBkZXZpY2UgKi8NCi0gICAgICBkZXYtPmJhc2Vf
YWRkciA9IGlvYWRkcjsNCi0NCi0gICAgICBpZiAobWNhX3Nsb3QgIT0gLTEp
IHsNCi0JcHJpbnRrKCIlczogJXMgYXQgMHglMDRseCAoTUNBIHNsb3QgJWQp
IiwgZGV2LT5uYW1lLCBuYW1lLCANCi0JICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW9hZGRyLCBtY2Ffc2xv
dCk7DQotICAgICAgfSBlbHNlIGlmICgoaW9hZGRyICYgMHgwZmZmKSA9PSBE
RVBDQV9FSVNBX0lPX1BPUlRTKSB7IC8qIEVJU0Egc2xvdCBhZGRyZXNzICov
DQotCXByaW50aygiJXM6ICVzIGF0IDB4JTA0bHggKEVJU0Egc2xvdCAlZCki
LCANCi0JICAgICAgICAgICAgICAgICAgICBkZXYtPm5hbWUsIG5hbWUsIGlv
YWRkciwgKGludCkoKGlvYWRkcj4+MTIpJjB4MGYpKTsNCi0gICAgICB9IGVs
c2UgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogSVNBIHBvcnQg
YWRkcmVzcyAqLw0KLQlwcmludGsoIiVzOiAlcyBhdCAweCUwNGx4IiwgZGV2
LT5uYW1lLCBuYW1lLCBpb2FkZHIpOw0KLSAgICAgIH0NCisJaWYgKGludyhE
RVBDQV9EQVRBKSAhPSBTVE9QKSB7DQorCQlyZXR1cm4gLUVOWElPOw0KKwl9
DQogDQotICAgICAgcHJpbnRrKCIsIGgvdyBhZGRyZXNzICIpOw0KLSAgICAg
IHN0YXR1cyA9IGdldF9od19hZGRyKGRldik7DQotICAgICAgZm9yIChpPTA7
IGk8RVRIX0FMRU4gLSAxOyBpKyspIHsgLyogZ2V0IHRoZSBldGhlcm5ldCBh
ZGRyZXNzICovDQotCXByaW50aygiJTIuMng6IiwgZGV2LT5kZXZfYWRkcltp
XSk7DQotICAgICAgfQ0KLSAgICAgIHByaW50aygiJTIuMngiLCBkZXYtPmRl
dl9hZGRyW2ldKTsNCisJZG8gew0KKwkJc3RyY3B5KG5hbWUsIChhZGFwdGVy
X25hbWUgPyBhZGFwdGVyX25hbWUgOiAiIikpOw0KKwkJbWVtX3N0YXJ0ID0g
KG1lbSA/IG1lbSAmIDB4ZjAwMDAgOiBtZW1fYmFzZVttZW1fY2hrZCsrXSk7
DQorCQlEZXBjYVNpZ25hdHVyZShuYW1lLCBtZW1fc3RhcnQpOw0KKwl9IHdo
aWxlICghbWVtICYmIG1lbV9iYXNlW21lbV9jaGtkXSAmJiAoYWRhcHRlciA9
PSB1bmtub3duKSk7DQorDQorCWlmICgoYWRhcHRlciA9PSB1bmtub3duKSB8
fCAhbWVtX3N0YXJ0KSB7IC8qIERFUENBIGRldmljZSBub3QgZm91bmQgKi8N
CisJCXJldHVybiAtRU5YSU87DQorCX0NCisNCisJZGV2LT5iYXNlX2FkZHIg
PSBpb2FkZHI7DQorDQorCWlmIChtY2Ffc2xvdCAhPSAtMSkgew0KKwkJcHJp
bnRrKCIlczogJXMgYXQgMHglMDRseCAoTUNBIHNsb3QgJWQpIiwgZGV2LT5u
YW1lLCBuYW1lLCANCisJCSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGlvYWRkciwgbWNhX3Nsb3QpOw0KKwl9IGVsc2UgaWYg
KChpb2FkZHIgJiAweDBmZmYpID09IERFUENBX0VJU0FfSU9fUE9SVFMpIHsg
LyogRUlTQSBzbG90IGFkZHJlc3MgKi8NCisJCXByaW50aygiJXM6ICVzIGF0
IDB4JTA0bHggKEVJU0Egc2xvdCAlZCkiLCANCisJCSAgICAgICBkZXYtPm5h
bWUsIG5hbWUsIGlvYWRkciwgKGludCkoKGlvYWRkcj4+MTIpJjB4MGYpKTsN
CisJfSBlbHNlIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8qIElT
QSBwb3J0IGFkZHJlc3MgKi8NCisJCXByaW50aygiJXM6ICVzIGF0IDB4JTA0
bHgiLCBkZXYtPm5hbWUsIG5hbWUsIGlvYWRkcik7DQorCX0NCisNCisJcHJp
bnRrKCIsIGgvdyBhZGRyZXNzICIpOw0KKwlzdGF0dXMgPSBnZXRfaHdfYWRk
cihkZXYpOw0KKwlmb3IgKGk9MDsgaTxFVEhfQUxFTiAtIDE7IGkrKykgeyAv
KiBnZXQgdGhlIGV0aGVybmV0IGFkZHJlc3MgKi8NCisJCXByaW50aygiJTIu
Mng6IiwgZGV2LT5kZXZfYWRkcltpXSk7DQorCX0NCisJcHJpbnRrKCIlMi4y
eCIsIGRldi0+ZGV2X2FkZHJbaV0pOw0KKw0KKwlpZiAoc3RhdHVzICE9IDAp
IHsNCisJCXByaW50aygiICAgICAgd2hpY2ggaGFzIGFuIEV0aGVybmV0IFBS
T00gQ1JDIGVycm9yLlxuIik7DQorCQlyZXR1cm4gLUVOWElPOw0KKwl9DQog
DQotICAgICAgaWYgKHN0YXR1cyA9PSAwKSB7DQogCS8qIFNldCB1cCB0aGUg
bWF4aW11bSBhbW91bnQgb2YgbmV0d29yayBSQU0oa0IpICovDQogCW5ldFJB
TSA9ICgoYWRhcHRlciAhPSBERVBDQSkgPyA2NCA6IDQ4KTsNCi0JaWYgKChu
aWNzciAmIF8xMjhLQikgJiYgKGFkYXB0ZXIgPT0gZGU0MjIpKSBuZXRSQU0g
PSAxMjg7DQorCWlmICgobmljc3IgJiBfMTI4S0IpICYmIChhZGFwdGVyID09
IGRlNDIyKSkNCisJCW5ldFJBTSA9IDEyODsNCiAJb2Zmc2V0ID0gMHgwMDAw
Ow0KIA0KIAkvKiBTaGFyZWQgTWVtb3J5IEJhc2UgQWRkcmVzcyAqLyANCiAJ
aWYgKG5pY3NyICYgQlVGKSB7DQotCSAgb2Zmc2V0ID0gMHg4MDAwOyAgICAg
ICAgICAgICAgLyogMzJrYnl0ZSBSQU0gb2Zmc2V0Ki8NCi0JICBuaWNzciAm
PSB+QlM7ICAgICAgICAgICAgICAgICAvKiBERVBDQSBSQU0gaW4gdG9wIDMy
ayAqLw0KLQkgIG5ldFJBTSAtPSAzMjsNCisJCW9mZnNldCA9IDB4ODAwMDsg
ICAgICAgIC8qIDMya2J5dGUgUkFNIG9mZnNldCovDQorCQluaWNzciAmPSB+
QlM7ICAgICAgICAgICAvKiBERVBDQSBSQU0gaW4gdG9wIDMyayAqLw0KKwkJ
bmV0UkFNIC09IDMyOw0KIAl9DQogCW1lbV9zdGFydCArPSBvZmZzZXQ7ICAg
ICAgICAgICAgLyogKEUpSVNBIHN0YXJ0IGFkZHJlc3MgKi8NCiAJaWYgKCht
ZW1fbGVuID0gKE5VTV9SWF9ERVNDKihzaXplb2Yoc3RydWN0IGRlcGNhX3J4
X2Rlc2MpK1JYX0JVRkZfU1opICsNCiAJCQlOVU1fVFhfREVTQyooc2l6ZW9m
KHN0cnVjdCBkZXBjYV90eF9kZXNjKStUWF9CVUZGX1NaKSArDQotCQkJc2l6
ZW9mKHN0cnVjdCBkZXBjYV9pbml0KSkpIDw9DQotCSAgICAobmV0UkFNPDwx
MCkpIHsNCi0JICBwcmludGsoIixcbiAgICAgIGhhcyAlZGtCIFJBTSBhdCAw
eCUuNWx4IiwgbmV0UkFNLCBtZW1fc3RhcnQpOw0KLQ0KLQkgIC8qIEVuYWJs
ZSB0aGUgc2hhZG93IFJBTS4gKi8NCi0JICBpZiAoYWRhcHRlciAhPSBERVBD
QSkgew0KLQkgICAgbmljc3IgfD0gU0hFOw0KLQkgICAgb3V0YihuaWNzciwg
REVQQ0FfTklDU1IpOw0KLQkgIH0NCisJCQlzaXplb2Yoc3RydWN0IGRlcGNh
X2luaXQpKSkNCisJICAgID4gKG5ldFJBTTw8MTApKSB7DQorCQlwcmludGso
IixcbiAgICAgICByZXF1ZXN0cyAlZGtCIFJBTTogb25seSAlZGtCIGlzIGF2
YWlsYWJsZSFcbiIsDQorCQkgICAgICAgIChtZW1fbGVuID4+IDEwKSwgbmV0
UkFNKTsNCisJCXJldHVybiAtRU5YSU87DQorCX0NCisNCisJcHJpbnRrKCIs
XG4gICAgICBoYXMgJWRrQiBSQU0gYXQgMHglLjVseCIsIG5ldFJBTSwgbWVt
X3N0YXJ0KTsNCisNCisJLyogRW5hYmxlIHRoZSBzaGFkb3cgUkFNLiAqLw0K
KwlpZiAoYWRhcHRlciAhPSBERVBDQSkgew0KKwkJbmljc3IgfD0gU0hFOw0K
KwkJb3V0YihuaWNzciwgREVQQ0FfTklDU1IpOw0KKwl9DQogIA0KLQkgIC8q
IERlZmluZSB0aGUgZGV2aWNlIHByaXZhdGUgbWVtb3J5ICovDQotCSAgZGV2
LT5wcml2ID0gKHZvaWQgKikga21hbGxvYyhzaXplb2Yoc3RydWN0IGRlcGNh
X3ByaXZhdGUpLCBHRlBfS0VSTkVMKTsNCi0JICBpZiAoZGV2LT5wcml2ID09
IE5VTEwpDQotCSAgICByZXR1cm4gLUVOT01FTTsNCi0JICBscCA9IChzdHJ1
Y3QgZGVwY2FfcHJpdmF0ZSAqKWRldi0+cHJpdjsNCi0JICBtZW1zZXQoKGNo
YXIgKilkZXYtPnByaXYsIDAsIHNpemVvZihzdHJ1Y3QgZGVwY2FfcHJpdmF0
ZSkpOw0KLQkgIGxwLT5hZGFwdGVyID0gYWRhcHRlcjsNCi0JICBscC0+bWNh
X3Nsb3QgPSBtY2Ffc2xvdDsNCi0JICBscC0+bG9jayA9IFNQSU5fTE9DS19V
TkxPQ0tFRDsNCi0gCSAgc3ByaW50ZihscC0+YWRhcHRlcl9uYW1lLCIlcyAo
JXMpIiwgbmFtZSwgZGV2LT5uYW1lKTsNCi0JICByZXF1ZXN0X3JlZ2lvbihp
b2FkZHIsIERFUENBX1RPVEFMX1NJWkUsIGxwLT5hZGFwdGVyX25hbWUpOw0K
LQ0KLQkgIC8qIEluaXRpYWxpc2F0aW9uIEJsb2NrICovDQotCSAgbHAtPnNo
X21lbSA9IG1lbV9zdGFydDsNCi0JICBtZW1fc3RhcnQgKz0gc2l6ZW9mKHN0
cnVjdCBkZXBjYV9pbml0KTsNCi0NCi0JICAvKiBUeCAmIFJ4IGRlc2NyaXB0
b3JzIChhbGlnbmVkIHRvIGEgcXVhZHdvcmQgYm91bmRhcnkpICovDQotCSAg
bWVtX3N0YXJ0ID0gKG1lbV9zdGFydCArIEFMSUdOKSAmIH5BTElHTjsNCi0J
ICBscC0+cnhfcmluZyA9IChzdHJ1Y3QgZGVwY2FfcnhfZGVzYyAqKW1lbV9z
dGFydDsNCi0NCi0JICBtZW1fc3RhcnQgKz0gKHNpemVvZihzdHJ1Y3QgZGVw
Y2FfcnhfZGVzYykgKiBOVU1fUlhfREVTQyk7DQotCSAgbHAtPnR4X3Jpbmcg
PSAoc3RydWN0IGRlcGNhX3R4X2Rlc2MgKiltZW1fc3RhcnQ7DQotDQotCSAg
bWVtX3N0YXJ0ICs9IChzaXplb2Yoc3RydWN0IGRlcGNhX3R4X2Rlc2MpICog
TlVNX1RYX0RFU0MpOw0KLQkgIGxwLT5idXNfb2Zmc2V0ID0gbWVtX3N0YXJ0
ICYgMHgwMGZmMDAwMDsNCi0JICBtZW1fc3RhcnQgJj0gTEFfTUFTSzsgICAg
ICAgICAgIC8qIExBTkNFIHJlLW1hcHBlZCBzdGFydCBhZGRyZXNzICovDQot
DQotCSAgbHAtPmRtYV9idWZmcyA9IG1lbV9zdGFydDsNCi0NCi0JICAvKiBG
aW5pc2ggaW5pdGlhbGlzaW5nIHRoZSByaW5nIGluZm9ybWF0aW9uLiAqLw0K
LQkgIGxwLT5yeFJpbmdNYXNrID0gTlVNX1JYX0RFU0MgLSAxOw0KLQkgIGxw
LT50eFJpbmdNYXNrID0gTlVNX1RYX0RFU0MgLSAxOw0KLQ0KLQkgIC8qIENh
bGN1bGF0ZSBUeC9SeCBSTEVOIHNpemUgZm9yIHRoZSBkZXNjcmlwdG9ycy4g
Ki8NCi0JICBmb3IgKGk9MCwgaiA9IGxwLT5yeFJpbmdNYXNrOyBqPjA7IGkr
Kykgew0KLQkgICAgaiA+Pj0gMTsNCi0JICB9DQotCSAgbHAtPnJ4X3JsZW4g
PSAoczMyKShpIDw8IDI5KTsNCi0JICBmb3IgKGk9MCwgaiA9IGxwLT50eFJp
bmdNYXNrOyBqPjA7IGkrKykgew0KLQkgICAgaiA+Pj0gMTsNCi0JICB9DQot
CSAgbHAtPnR4X3JsZW4gPSAoczMyKShpIDw8IDI5KTsNCisJLyogRGVmaW5l
IHRoZSBkZXZpY2UgcHJpdmF0ZSBtZW1vcnkgKi8NCisJZGV2LT5wcml2ID0g
KHZvaWQgKikga21hbGxvYyhzaXplb2Yoc3RydWN0IGRlcGNhX3ByaXZhdGUp
LCBHRlBfS0VSTkVMKTsNCisJaWYgKGRldi0+cHJpdiA9PSBOVUxMKQ0KKwkJ
cmV0dXJuIC1FTk9NRU07DQorCWxwID0gKHN0cnVjdCBkZXBjYV9wcml2YXRl
ICopZGV2LT5wcml2Ow0KKwltZW1zZXQoKGNoYXIgKilkZXYtPnByaXYsIDAs
IHNpemVvZihzdHJ1Y3QgZGVwY2FfcHJpdmF0ZSkpOw0KKwlscC0+YWRhcHRl
ciA9IGFkYXB0ZXI7DQorCWxwLT5tY2Ffc2xvdCA9IG1jYV9zbG90Ow0KKwls
cC0+bG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRDsNCisgCXNwcmludGYobHAt
PmFkYXB0ZXJfbmFtZSwiJXMgKCVzKSIsIG5hbWUsIGRldi0+bmFtZSk7DQor
CXJlcXVlc3RfcmVnaW9uKGlvYWRkciwgREVQQ0FfVE9UQUxfU0laRSwgbHAt
PmFkYXB0ZXJfbmFtZSk7DQorDQorCS8qIEluaXRpYWxpc2F0aW9uIEJsb2Nr
ICovDQorCWxwLT5zaF9tZW0gPSBpb3JlbWFwKG1lbV9zdGFydCwgbWVtX2xl
bik7DQorCWxwLT5kZXZpY2VfcmFtX3N0YXJ0ID0gbWVtX3N0YXJ0ICYgTEFf
TUFTSzsNCisNCisJb2Zmc2V0ID0gMDsNCisJb2Zmc2V0ICs9IHNpemVvZihz
dHJ1Y3QgZGVwY2FfaW5pdCk7DQorDQorCS8qIFR4ICYgUnggZGVzY3JpcHRv
cnMgKGFsaWduZWQgdG8gYSBxdWFkd29yZCBib3VuZGFyeSkgKi8NCisJb2Zm
c2V0ID0gKG9mZnNldCArIEFMSUdOKSAmIH5BTElHTjsNCisJbHAtPnJ4X3Jp
bmcgPSAoc3RydWN0IGRlcGNhX3J4X2Rlc2MgKikobHAtPnNoX21lbSArIG9m
ZnNldCk7DQorCWxwLT5yeF9yaW5nX29mZnNldCA9IG9mZnNldDsNCisNCisJ
b2Zmc2V0ICs9IChzaXplb2Yoc3RydWN0IGRlcGNhX3J4X2Rlc2MpICogTlVN
X1JYX0RFU0MpOw0KKwlscC0+dHhfcmluZyA9IChzdHJ1Y3QgZGVwY2FfdHhf
ZGVzYyAqKShscC0+c2hfbWVtICsgb2Zmc2V0KTsNCisJbHAtPnR4X3Jpbmdf
b2Zmc2V0ID0gb2Zmc2V0Ow0KKw0KKwlvZmZzZXQgKz0gKHNpemVvZihzdHJ1
Y3QgZGVwY2FfdHhfZGVzYykgKiBOVU1fVFhfREVTQyk7DQorDQorCWxwLT5i
dWZmc19vZmZzZXQgPSBvZmZzZXQ7DQorDQorCS8qIEZpbmlzaCBpbml0aWFs
aXNpbmcgdGhlIHJpbmcgaW5mb3JtYXRpb24uICovDQorCWxwLT5yeFJpbmdN
YXNrID0gTlVNX1JYX0RFU0MgLSAxOw0KKwlscC0+dHhSaW5nTWFzayA9IE5V
TV9UWF9ERVNDIC0gMTsNCisNCisJLyogQ2FsY3VsYXRlIFR4L1J4IFJMRU4g
c2l6ZSBmb3IgdGhlIGRlc2NyaXB0b3JzLiAqLw0KKwlmb3IgKGk9MCwgaiA9
IGxwLT5yeFJpbmdNYXNrOyBqPjA7IGkrKykgew0KKwkJaiA+Pj0gMTsNCisJ
fQ0KKwlscC0+cnhfcmxlbiA9IChzMzIpKGkgPDwgMjkpOw0KKwlmb3IgKGk9
MCwgaiA9IGxwLT50eFJpbmdNYXNrOyBqPjA7IGkrKykgew0KKwkJaiA+Pj0g
MTsNCisJfQ0KKwlscC0+dHhfcmxlbiA9IChzMzIpKGkgPDwgMjkpOw0KIA0K
LQkgIC8qIExvYWQgdGhlIGluaXRpYWxpc2F0aW9uIGJsb2NrICovDQotCSAg
ZGVwY2FfaW5pdF9yaW5nKGRldik7DQorCS8qIExvYWQgdGhlIGluaXRpYWxp
c2F0aW9uIGJsb2NrICovDQorCWRlcGNhX2luaXRfcmluZyhkZXYpOw0KIA0K
LQkgIC8qIEluaXRpYWxpc2UgdGhlIGNvbnRyb2wgYW5kIHN0YXR1cyByZWdp
c3RlcnMgKi8NCi0JICBMb2FkQ1NScyhkZXYpOw0KKwkvKiBJbml0aWFsaXNl
IHRoZSBjb250cm9sIGFuZCBzdGF0dXMgcmVnaXN0ZXJzICovDQorCUxvYWRD
U1JzKGRldik7DQogDQotCSAgLyogRW5hYmxlIERFUENBIGJvYXJkIGludGVy
cnVwdHMgZm9yIGF1dG9wcm9iaW5nICovDQotCSAgbmljc3IgPSAoKG5pY3Ny
ICYgfklNKXxJRU4pOw0KLQkgIG91dGIobmljc3IsIERFUENBX05JQ1NSKTsN
CisJLyogRW5hYmxlIERFUENBIGJvYXJkIGludGVycnVwdHMgZm9yIGF1dG9w
cm9iaW5nICovDQorCW5pY3NyID0gKChuaWNzciAmIH5JTSl8SUVOKTsNCisJ
b3V0YihuaWNzciwgREVQQ0FfTklDU1IpOw0KIA0KLQkgIC8qIFRvIGF1dG8t
SVJRIHdlIGVuYWJsZSB0aGUgaW5pdGlhbGl6YXRpb24tZG9uZSBhbmQgRE1B
IGVyciwNCi0JICAgICBpbnRlcnJ1cHRzLiBGb3Igbm93IHdlIHdpbGwgYWx3
YXlzIGdldCBhIERNQSBlcnJvci4gKi8NCi0JICBpZiAoZGV2LT5pcnEgPCAy
KSB7DQorCS8qIFRvIGF1dG8tSVJRIHdlIGVuYWJsZSB0aGUgaW5pdGlhbGl6
YXRpb24tZG9uZSBhbmQgRE1BIGVyciwNCisJICAgaW50ZXJydXB0cy4gRm9y
IG5vdyB3ZSB3aWxsIGFsd2F5cyBnZXQgYSBETUEgZXJyb3IuICovDQorCWlm
IChkZXYtPmlycSA8IDIpIHsNCiAjaWZuZGVmIE1PRFVMRQ0KLQkgICAgdW5z
aWduZWQgY2hhciBpcnFudW07DQotCSAgICBhdXRvaXJxX3NldHVwKDApOw0K
LQkgICAgDQotCSAgICAvKiBBc3NpZ24gdGhlIGNvcnJlY3QgaXJxIGxpc3Qg
Ki8NCi0JICAgIHN3aXRjaCAobHAtPmFkYXB0ZXIpIHsNCi0JICAgIGNhc2Ug
REVQQ0E6DQotCSAgICBjYXNlIGRlMTAwOg0KLQkgICAgY2FzZSBkZTEwMToN
Ci0JICAgICAgZGVwY2FfaXJxID0gZGUxeHhfaXJxOw0KLQkgICAgICBicmVh
azsNCi0JICAgIGNhc2UgZGUyMDA6DQotCSAgICBjYXNlIGRlMjAxOg0KLQkg
ICAgY2FzZSBkZTIwMjoNCi0JICAgIGNhc2UgZGUyMTA6DQotCSAgICBjYXNl
IGRlMjEyOg0KLQkgICAgICBkZXBjYV9pcnEgPSBkZTJ4eF9pcnE7DQotCSAg
ICAgIGJyZWFrOw0KLQkgICAgY2FzZSBkZTQyMjoNCi0JICAgICAgZGVwY2Ff
aXJxID0gZGU0MjJfaXJxOw0KLQkgICAgICBicmVhazsNCi0JICAgIH0NCisJ
CXVuc2lnbmVkIGNoYXIgaXJxbnVtOw0KKwkJYXV0b2lycV9zZXR1cCgwKTsN
CiANCi0JICAgIC8qIFRyaWdnZXIgYW4gaW5pdGlhbGl6YXRpb24ganVzdCBm
b3IgdGhlIGludGVycnVwdC4gKi8NCi0JICAgIG91dHcoSU5FQSB8IElOSVQs
IERFUENBX0RBVEEpOw0KLQkgIA0KLQkgICAgaXJxbnVtID0gYXV0b2lycV9y
ZXBvcnQoMSk7DQotCSAgICBpZiAoIWlycW51bSkgew0KLQkgICAgICBwcmlu
dGsoIiBhbmQgZmFpbGVkIHRvIGRldGVjdCBJUlEgbGluZS5cbiIpOw0KLQkg
ICAgICBzdGF0dXMgPSAtRU5YSU87DQotCSAgICB9IGVsc2Ugew0KLQkgICAg
ICBmb3IgKGRldi0+aXJxPTAsaT0wOyAoZGVwY2FfaXJxW2ldKSAmJiAoIWRl
di0+aXJxKTsgaSsrKSB7DQotCQlpZiAoaXJxbnVtID09IGRlcGNhX2lycVtp
XSkgew0KLQkJICBkZXYtPmlycSA9IGlycW51bTsNCi0JCSAgcHJpbnRrKCIg
YW5kIHVzZXMgSVJRJWQuXG4iLCBkZXYtPmlycSk7DQorCQkvKiBBc3NpZ24g
dGhlIGNvcnJlY3QgaXJxIGxpc3QgKi8NCisJCXN3aXRjaCAobHAtPmFkYXB0
ZXIpIHsNCisJCWNhc2UgREVQQ0E6DQorCQljYXNlIGRlMTAwOg0KKwkJY2Fz
ZSBkZTEwMToNCisJCQlkZXBjYV9pcnEgPSBkZTF4eF9pcnE7DQorCQkJYnJl
YWs7DQorCQljYXNlIGRlMjAwOg0KKwkJY2FzZSBkZTIwMToNCisJCWNhc2Ug
ZGUyMDI6DQorCQljYXNlIGRlMjEwOg0KKwkJY2FzZSBkZTIxMjoNCisJCQlk
ZXBjYV9pcnEgPSBkZTJ4eF9pcnE7DQorCQkJYnJlYWs7DQorCQljYXNlIGRl
NDIyOg0KKwkJCWRlcGNhX2lycSA9IGRlNDIyX2lycTsNCisJCQlicmVhazsN
CiAJCX0NCi0JICAgICAgfQ0KKw0KKwkJLyogVHJpZ2dlciBhbiBpbml0aWFs
aXphdGlvbiBqdXN0IGZvciB0aGUgaW50ZXJydXB0LiAqLw0KKwkJb3V0dyhJ
TkVBIHwgSU5JVCwgREVQQ0FfREFUQSk7DQorCSAgDQorCQlpcnFudW0gPSBh
dXRvaXJxX3JlcG9ydCgxKTsNCisJCWlmICghaXJxbnVtKSB7DQorCQkJcHJp
bnRrKCIgYW5kIGZhaWxlZCB0byBkZXRlY3QgSVJRIGxpbmUuXG4iKTsNCisJ
CQlzdGF0dXMgPSAtRU5YSU87DQorCQl9IGVsc2Ugew0KKwkJCWZvciAoZGV2
LT5pcnE9MCxpPTA7IChkZXBjYV9pcnFbaV0pICYmICghZGV2LT5pcnEpOyBp
KyspIHsNCisJCQkJaWYgKGlycW51bSA9PSBkZXBjYV9pcnFbaV0pIHsNCisJ
CQkJCWRldi0+aXJxID0gaXJxbnVtOw0KKwkJCQkJcHJpbnRrKCIgYW5kIHVz
ZXMgSVJRJWQuXG4iLCBkZXYtPmlycSk7DQorCQkJCX0NCisJCQl9DQogCSAg
ICAgIA0KLQkgICAgICBpZiAoIWRldi0+aXJxKSB7DQotCQlwcmludGsoIiBi
dXQgaW5jb3JyZWN0IElSUSBsaW5lIGRldGVjdGVkLlxuIik7DQotCQlzdGF0
dXMgPSAtRU5YSU87DQotCSAgICAgIH0NCi0JICAgIH0NCisJCQlpZiAoIWRl
di0+aXJxKSB7DQorCQkJCXByaW50aygiIGJ1dCBpbmNvcnJlY3QgSVJRIGxp
bmUgZGV0ZWN0ZWQuXG4iKTsNCisJCQkJc3RhdHVzID0gLUVOWElPOw0KKwkJ
CX0NCisJCX0NCiAjZW5kaWYgLyogTU9EVUxFICovDQotCSAgfSBlbHNlIHsN
Ci0JICAgIHByaW50aygiIGFuZCBhc3NpZ25lZCBJUlElZC5cbiIsIGRldi0+
aXJxKTsNCi0JICB9DQotCSAgaWYgKHN0YXR1cykgcmVsZWFzZV9yZWdpb24o
aW9hZGRyLCBERVBDQV9UT1RBTF9TSVpFKTsNCiAJfSBlbHNlIHsNCi0JICBw
cmludGsoIixcbiAgICAgIHJlcXVlc3RzICVka0IgUkFNOiBvbmx5ICVka0Ig
aXMgYXZhaWxhYmxlIVxuIiwgDQotCSAgICAgICAgIAkgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIChtZW1fbGVuPj4xMCksIG5ldFJBTSk7DQot
CSAgc3RhdHVzID0gLUVOWElPOw0KKwkJcHJpbnRrKCIgYW5kIGFzc2lnbmVk
IElSUSVkLlxuIiwgZGV2LT5pcnEpOw0KIAl9DQotICAgICAgfSBlbHNlIHsN
Ci0JcHJpbnRrKCIgICAgICB3aGljaCBoYXMgYW4gRXRoZXJuZXQgUFJPTSBD
UkMgZXJyb3IuXG4iKTsNCi0Jc3RhdHVzID0gLUVOWElPOw0KLSAgICAgIH0N
Ci0gICAgfSBlbHNlIHsNCi0gICAgICBzdGF0dXMgPSAtRU5YSU87DQotICAg
IH0NCi0gICAgaWYgKCFzdGF0dXMpIHsNCi0gICAgICBpZiAoZGVwY2FfZGVi
dWcgPiAxKSB7DQotCXByaW50ayh2ZXJzaW9uKTsNCi0gICAgICB9DQogDQot
ICAgICAgLyogVGhlIERFUENBLXNwZWNpZmljIGVudHJpZXMgaW4gdGhlIGRl
dmljZSBzdHJ1Y3R1cmUuICovDQotICAgICAgZGV2LT5vcGVuID0gJmRlcGNh
X29wZW47DQotICAgICAgZGV2LT5oYXJkX3N0YXJ0X3htaXQgPSAmZGVwY2Ff
c3RhcnRfeG1pdDsNCi0gICAgICBkZXYtPnN0b3AgPSAmZGVwY2FfY2xvc2U7
DQotICAgICAgZGV2LT5nZXRfc3RhdHMgPSAmZGVwY2FfZ2V0X3N0YXRzOw0K
LSAgICAgIGRldi0+c2V0X211bHRpY2FzdF9saXN0ID0gJnNldF9tdWx0aWNh
c3RfbGlzdDsNCi0gICAgICBkZXYtPmRvX2lvY3RsID0gJmRlcGNhX2lvY3Rs
Ow0KLSAgICAgIGRldi0+dHhfdGltZW91dCA9IGRlcGNhX3R4X3RpbWVvdXQ7
DQotICAgICAgZGV2LT53YXRjaGRvZ190aW1lbyA9IFRYX1RJTUVPVVQ7DQor
CWlmICghc3RhdHVzKSB7DQorCQlpZiAoZGVwY2FfZGVidWcgPiAxKSB7DQor
CQkJcHJpbnRrKHZlcnNpb24pOw0KKwkJfQ0KIA0KLSAgICAgIGRldi0+bWVt
X3N0YXJ0ID0gMDsNCi0JDQotICAgICAgLyogRmlsbCBpbiB0aGUgZ2VuZXJp
YyBmaWVsZCBvZiB0aGUgZGV2aWNlIHN0cnVjdHVyZS4gKi8NCi0gICAgICBl
dGhlcl9zZXR1cChkZXYpOw0KLSAgICB9IGVsc2UgeyAgICAgICAgICAgICAg
ICAgICAgICAgICAgIC8qIEluY29ycmVjdGx5IGluaXRpYWxpc2VkIGhhcmR3
YXJlICovDQotICAgICAgaWYgKGRldi0+cHJpdikgew0KLQlrZnJlZShkZXYt
PnByaXYpOw0KLQlkZXYtPnByaXYgPSBOVUxMOw0KLSAgICAgIH0NCi0gICAg
fQ0KLSAgfSBlbHNlIHsNCi0gICAgc3RhdHVzID0gLUVOWElPOw0KLSAgfQ0K
KwkJLyogVGhlIERFUENBLXNwZWNpZmljIGVudHJpZXMgaW4gdGhlIGRldmlj
ZSBzdHJ1Y3R1cmUuICovDQorCQlkZXYtPm9wZW4gPSAmZGVwY2Ffb3BlbjsN
CisJCWRldi0+aGFyZF9zdGFydF94bWl0ID0gJmRlcGNhX3N0YXJ0X3htaXQ7
DQorCQlkZXYtPnN0b3AgPSAmZGVwY2FfY2xvc2U7DQorCQlkZXYtPmdldF9z
dGF0cyA9ICZkZXBjYV9nZXRfc3RhdHM7DQorCQlkZXYtPnNldF9tdWx0aWNh
c3RfbGlzdCA9ICZzZXRfbXVsdGljYXN0X2xpc3Q7DQorCQlkZXYtPmRvX2lv
Y3RsID0gJmRlcGNhX2lvY3RsOw0KKwkJZGV2LT50eF90aW1lb3V0ID0gZGVw
Y2FfdHhfdGltZW91dDsNCisJCWRldi0+d2F0Y2hkb2dfdGltZW8gPSBUWF9U
SU1FT1VUOw0KKw0KKwkJZGV2LT5tZW1fc3RhcnQgPSAwOw0KKw0KKwkJLyog
RmlsbCBpbiB0aGUgZ2VuZXJpYyBmaWVsZCBvZiB0aGUgZGV2aWNlIHN0cnVj
dHVyZS4gKi8NCisJCWV0aGVyX3NldHVwKGRldik7DQorCX0gZWxzZSB7ICAg
ICAgICAgIC8qIEluY29ycmVjdGx5IGluaXRpYWxpc2VkIGhhcmR3YXJlICov
DQorCQlyZWxlYXNlX3JlZ2lvbihpb2FkZHIsIERFUENBX1RPVEFMX1NJWkUp
Ow0KKwkJaWYgKGRldi0+cHJpdikgew0KKwkJCWtmcmVlKGRldi0+cHJpdik7
DQorCQkJZGV2LT5wcml2ID0gTlVMTDsNCisJCX0NCisJfQ0KIA0KLSAgcmV0
dXJuIHN0YXR1czsNCisJcmV0dXJuIHN0YXR1czsNCiB9DQogDQogDA0KQEAg
LTc4MSwzOSArNzk0LDQzIEBADQogc3RhdGljIHZvaWQNCiBkZXBjYV9pbml0
X3Jpbmcoc3RydWN0IG5ldF9kZXZpY2UgKmRldikNCiB7DQotICBzdHJ1Y3Qg
ZGVwY2FfcHJpdmF0ZSAqbHAgPSAoc3RydWN0IGRlcGNhX3ByaXZhdGUgKilk
ZXYtPnByaXY7DQotICB1X2ludCBpOw0KLSAgdV9sb25nIHA7DQotDQotICAv
KiBMb2NrIG91dCBvdGhlciBwcm9jZXNzZXMgd2hpbHN0IHNldHRpbmcgdXAg
dGhlIGhhcmR3YXJlICovDQotICBuZXRpZl9zdG9wX3F1ZXVlKGRldik7DQot
DQotICBscC0+cnhfbmV3ID0gbHAtPnR4X25ldyA9IDA7DQotICBscC0+cnhf
b2xkID0gbHAtPnR4X29sZCA9IDA7DQorCXN0cnVjdCBkZXBjYV9wcml2YXRl
ICpscCA9IChzdHJ1Y3QgZGVwY2FfcHJpdmF0ZSAqKWRldi0+cHJpdjsNCisJ
dV9pbnQgaTsNCisJdV9sb25nIG9mZnNldDsNCisNCisJLyogTG9jayBvdXQg
b3RoZXIgcHJvY2Vzc2VzIHdoaWxzdCBzZXR0aW5nIHVwIHRoZSBoYXJkd2Fy
ZSAqLw0KKwluZXRpZl9zdG9wX3F1ZXVlKGRldik7DQorDQorCWxwLT5yeF9u
ZXcgPSBscC0+dHhfbmV3ID0gMDsNCisJbHAtPnJ4X29sZCA9IGxwLT50eF9v
bGQgPSAwOw0KKw0KKwkvKiBJbml0aWFsaXplIHRoZSBiYXNlIGFkZHJlc3Mg
YW5kIGxlbmd0aCBvZiBlYWNoIGJ1ZmZlciBpbiB0aGUgcmluZyAqLw0KKwlm
b3IgKGkgPSAwOyBpIDw9IGxwLT5yeFJpbmdNYXNrOyBpKyspIHsNCisJCW9m
ZnNldCA9IGxwLT5idWZmc19vZmZzZXQgKyBpKlJYX0JVRkZfU1o7DQorCQl3
cml0ZWwoKGxwLT5kZXZpY2VfcmFtX3N0YXJ0ICsgb2Zmc2V0KSB8IFJfT1dO
LA0KKwkJICAgICAgICZscC0+cnhfcmluZ1tpXS5iYXNlKTsNCisJCXdyaXRl
dygtUlhfQlVGRl9TWiwgJmxwLT5yeF9yaW5nW2ldLmJ1Zl9sZW5ndGgpOw0K
KwkJbHAtPnJ4X2J1ZmZbaV0gPSBscC0+c2hfbWVtICsgb2Zmc2V0Ow0KKwl9
DQogDQotICAvKiBJbml0aWFsaXplIHRoZSBiYXNlIGFkZHJlc3NlcyBhbmQg
bGVuZ3RoIG9mIGVhY2ggYnVmZmVyIGluIHRoZSByaW5nICovDQotICBmb3Ig
KGkgPSAwOyBpIDw9IGxwLT5yeFJpbmdNYXNrOyBpKyspIHsNCi0gICAgd3Jp
dGVsKChwPWxwLT5kbWFfYnVmZnMraSpSWF9CVUZGX1NaKSB8IFJfT1dOLCAm
bHAtPnJ4X3JpbmdbaV0uYmFzZSk7DQotICAgIHdyaXRldygtUlhfQlVGRl9T
WiwgJmxwLT5yeF9yaW5nW2ldLmJ1Zl9sZW5ndGgpOw0KLSAgICBscC0+cnhf
bWVtY3B5W2ldPShjaGFyICopKHArbHAtPmJ1c19vZmZzZXQpOw0KLSAgfQ0K
LSAgZm9yIChpID0gMDsgaSA8PSBscC0+dHhSaW5nTWFzazsgaSsrKSB7DQot
ICAgIHdyaXRlbCgocD1scC0+ZG1hX2J1ZmZzKyhpK2xwLT50eFJpbmdNYXNr
KzEpKlRYX0JVRkZfU1opICYgMHgwMGZmZmZmZiwNCi0JICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZscC0+dHhf
cmluZ1tpXS5iYXNlKTsNCi0gICAgbHAtPnR4X21lbWNweVtpXT0oY2hhciAq
KShwK2xwLT5idXNfb2Zmc2V0KTsNCi0gIH0NCisJZm9yIChpID0gMDsgaSA8
PSBscC0+dHhSaW5nTWFzazsgaSsrKSB7DQorCQlvZmZzZXQgPSBscC0+YnVm
ZnNfb2Zmc2V0ICsgKGkgKyBscC0+cnhSaW5nTWFzaysxKSpUWF9CVUZGX1Na
Ow0KKwkJd3JpdGVsKChscC0+ZGV2aWNlX3JhbV9zdGFydCArIG9mZnNldCkg
JiAweDAwZmZmZmZmLA0KKwkgICAgICAgICAgICAgICAmbHAtPnR4X3Jpbmdb
aV0uYmFzZSk7DQorCQlscC0+dHhfYnVmZltpXSA9IGxwLT5zaF9tZW0gKyBv
ZmZzZXQ7DQorCX0NCiANCi0gIC8qIFNldCB1cCB0aGUgaW5pdGlhbGl6YXRp
b24gYmxvY2sgKi8NCi0gIGxwLT5pbml0X2Jsb2NrLnJ4X3JpbmcgPSAoKHUz
MikoKHVfbG9uZylscC0+cnhfcmluZykmTEFfTUFTSykgfCBscC0+cnhfcmxl
bjsNCi0gIGxwLT5pbml0X2Jsb2NrLnR4X3JpbmcgPSAoKHUzMikoKHVfbG9u
ZylscC0+dHhfcmluZykmTEFfTUFTSykgfCBscC0+dHhfcmxlbjsNCisJLyog
U2V0IHVwIHRoZSBpbml0aWFsaXphdGlvbiBibG9jayAqLw0KKwlscC0+aW5p
dF9ibG9jay5yeF9yaW5nID0gKGxwLT5kZXZpY2VfcmFtX3N0YXJ0ICsgbHAt
PnJ4X3Jpbmdfb2Zmc2V0KSB8IGxwLT5yeF9ybGVuOw0KKwlscC0+aW5pdF9i
bG9jay50eF9yaW5nID0gKGxwLT5kZXZpY2VfcmFtX3N0YXJ0ICsgbHAtPnR4
X3Jpbmdfb2Zmc2V0KSB8IGxwLT50eF9ybGVuOw0KIA0KLSAgU2V0TXVsdGlj
YXN0RmlsdGVyKGRldik7DQorCVNldE11bHRpY2FzdEZpbHRlcihkZXYpOw0K
IA0KLSAgZm9yIChpID0gMDsgaSA8IEVUSF9BTEVOOyBpKyspIHsNCi0gICAg
bHAtPmluaXRfYmxvY2sucGh5c19hZGRyW2ldID0gZGV2LT5kZXZfYWRkcltp
XTsNCi0gIH0NCisJZm9yIChpID0gMDsgaSA8IEVUSF9BTEVOOyBpKyspIHsN
CisJCWxwLT5pbml0X2Jsb2NrLnBoeXNfYWRkcltpXSA9IGRldi0+ZGV2X2Fk
ZHJbaV07DQorCX0NCiANCi0gIGxwLT5pbml0X2Jsb2NrLm1vZGUgPSAweDAw
MDA7ICAgICAgICAgICAgLyogRW5hYmxlIHRoZSBUeCBhbmQgUnggKi8NCisJ
bHAtPmluaXRfYmxvY2subW9kZSA9IDB4MDAwMDsgICAgICAgICAgICAvKiBF
bmFibGUgdGhlIFR4IGFuZCBSeCAqLw0KIH0NCiANCiANCkBAIC05MDgsMTIg
KzkyNSwxMiBAQA0KIAkvKiBBbnkgcmVzb3VyY2VzIGF2YWlsYWJsZT8gKi8N
CiAJaWYgKChUWF9CVUZGU19BVkFJTCA+PSAwKSAmJiBuZXRpZl9xdWV1ZV9z
dG9wcGVkKGRldikpIHsNCiAJCW5ldGlmX3dha2VfcXVldWUgKGRldik7DQot
DQotCQkvKiBVbm1hc2sgdGhlIERFUENBIGJvYXJkIGludGVycnVwdHMgYW5k
IHR1cm4gb2ZmIHRoZSBMRUQgKi8NCi0JCW5pY3NyID0gKG5pY3NyICYgfklN
ICYgfkxFRCk7DQotCQlvdXRiIChuaWNzciwgREVQQ0FfTklDU1IpOw0KIAl9
DQogDQorCS8qIFVubWFzayB0aGUgREVQQ0EgYm9hcmQgaW50ZXJydXB0cyBh
bmQgdHVybiBvZmYgdGhlIExFRCAqLw0KKwluaWNzciA9IChuaWNzciAmIH5J
TSAmIH5MRUQpOw0KKwlvdXRiIChuaWNzciwgREVQQ0FfTklDU1IpOw0KKw0K
IAlzcGluX3VubG9jayAoJmxwLT5sb2NrKTsNCiB9DQogDQpAQCAtOTUxLDEw
ICs5NjgsMTAgQEANCiAJICBza2ItPmRldiA9IGRldjsNCiAJICBpZiAoZW50
cnkgPCBscC0+cnhfb2xkKSB7ICAgICAgICAgLyogV3JhcHBlZCBidWZmZXIg
Ki8NCiAJICAgIGxlbiA9IChscC0+cnhSaW5nTWFzayAtIGxwLT5yeF9vbGQg
KyAxKSAqIFJYX0JVRkZfU1o7DQotCSAgICBtZW1jcHlfZnJvbWlvKGJ1Ziwg
bHAtPnJ4X21lbWNweVtscC0+cnhfb2xkXSwgbGVuKTsNCi0JICAgIG1lbWNw
eV9mcm9taW8oYnVmICsgbGVuLCBscC0+cnhfbWVtY3B5WzBdLCBwa3RfbGVu
LWxlbik7DQorCSAgICBtZW1jcHlfZnJvbWlvKGJ1ZiwgbHAtPnJ4X2J1ZmZb
bHAtPnJ4X29sZF0sIGxlbik7DQorCSAgICBtZW1jcHlfZnJvbWlvKGJ1ZiAr
IGxlbiwgbHAtPnJ4X2J1ZmZbMF0sIHBrdF9sZW4tbGVuKTsNCiAJICB9IGVs
c2UgeyAgICAgICAgICAgICAgICAgICAgICAgICAgLyogTGluZWFyIGJ1ZmZl
ciAqLw0KLQkgICAgbWVtY3B5X2Zyb21pbyhidWYsIGxwLT5yeF9tZW1jcHlb
bHAtPnJ4X29sZF0sIHBrdF9sZW4pOw0KKwkgICAgbWVtY3B5X2Zyb21pbyhi
dWYsIGxwLT5yeF9idWZmW2xwLT5yeF9vbGRdLCBwa3RfbGVuKTsNCiAJICB9
DQogDQogCSAgLyogDQpAQCAtMTEwMyw5ICsxMTIwLDkgQEANCiAgIHVfbG9u
ZyBpb2FkZHIgPSBkZXYtPmJhc2VfYWRkcjsNCiANCiAgIG91dHcoQ1NSMSwg
REVQQ0FfQUREUik7ICAgICAgICAgICAgICAgIC8qIGluaXRpYWxpc2F0aW9u
IGJsb2NrIGFkZHJlc3MgTFNXICovDQotICBvdXR3KCh1MTYpKGxwLT5zaF9t
ZW0gJiBMQV9NQVNLKSwgREVQQ0FfREFUQSk7DQorICBvdXR3KCh1MTYpbHAt
PmRldmljZV9yYW1fc3RhcnQsIERFUENBX0RBVEEpOw0KICAgb3V0dyhDU1Iy
LCBERVBDQV9BRERSKTsgICAgICAgICAgICAgICAgLyogaW5pdGlhbGlzYXRp
b24gYmxvY2sgYWRkcmVzcyBNU1cgKi8NCi0gIG91dHcoKHUxNikoKGxwLT5z
aF9tZW0gJiBMQV9NQVNLKSA+PiAxNiksIERFUENBX0RBVEEpOw0KKyAgb3V0
dygodTE2KShscC0+ZGV2aWNlX3JhbV9zdGFydCA+PiAxNiksIERFUENBX0RB
VEEpOw0KICAgb3V0dyhDU1IzLCBERVBDQV9BRERSKTsgICAgICAgICAgICAg
ICAgLyogQUxFIGNvbnRyb2wgKi8NCiAgIG91dHcoQUNPTiwgREVQQ0FfREFU
QSk7DQogDQpAQCAtMTEyMSw3ICsxMTM4LDcgQEANCiAgIGludCBpLCBzdGF0
dXM9MDsNCiANCiAgIC8qIENvcHkgdGhlIHNoYWRvdyBpbml0X2Jsb2NrIHRv
IHNoYXJlZCBtZW1vcnkgKi8NCi0gIG1lbWNweV90b2lvKChjaGFyICopbHAt
PnNoX21lbSwgJmxwLT5pbml0X2Jsb2NrLCBzaXplb2Yoc3RydWN0IGRlcGNh
X2luaXQpKTsNCisgIG1lbWNweV90b2lvKGxwLT5zaF9tZW0sICZscC0+aW5p
dF9ibG9jaywgc2l6ZW9mKHN0cnVjdCBkZXBjYV9pbml0KSk7DQogDQogICBv
dXR3KENTUjAsIERFUENBX0FERFIpOyAgICAgICAgICAgICAgICAvKiBwb2lu
dCBiYWNrIHRvIENTUjAgKi8NCiAgIG91dHcoSU5JVCwgREVQQ0FfREFUQSk7
ICAgICAgICAgICAgICAgIC8qIGluaXRpYWxpemUgREVQQ0EgKi8NCkBAIC0x
MTM0LDExICsxMTUxLDExIEBADQogICAgIG91dHcoSURPTiB8IElORUEgfCBT
VFJULCBERVBDQV9EQVRBKTsNCiAgICAgaWYgKGRlcGNhX2RlYnVnID4gMikg
ew0KICAgICAgIHByaW50aygiJXM6IERFUENBIG9wZW4gYWZ0ZXIgJWQgdGlj
a3MsIGluaXQgYmxvY2sgMHglMDhseCBjc3IwICU0LjR4LlxuIiwNCi0JICAg
ICBkZXYtPm5hbWUsIGksIGxwLT5zaF9tZW0sIGludyhERVBDQV9EQVRBKSk7
DQorCSAgICAgZGV2LT5uYW1lLCBpLCB2aXJ0X3RvX3BoeXMobHAtPnNoX21l
bSksIGludyhERVBDQV9EQVRBKSk7DQogICAgIH0NCiAgIH0gZWxzZSB7DQog
ICAgIHByaW50aygiJXM6IERFUENBIHVub3BlbiBhZnRlciAlZCB0aWNrcywg
aW5pdCBibG9jayAweCUwOGx4IGNzcjAgJTQuNHguXG4iLA0KLQkgICAgIGRl
di0+bmFtZSwgaSwgbHAtPnNoX21lbSwgaW53KERFUENBX0RBVEEpKTsNCisJ
ICAgICBkZXYtPm5hbWUsIGksIHZpcnRfdG9fcGh5cyhscC0+c2hfbWVtKSwg
aW53KERFUENBX0RBVEEpKTsNCiAgICAgc3RhdHVzID0gLTE7DQogICB9DQog
DQpAQCAtMTU2OSwxMiArMTU4NiwxNSBAQA0KIHsNCiAgIHVfaW50IGksaixr
Ow0KICAgY29uc3QgY2hhciAqc2lnbmF0dXJlc1tdID0gREVQQ0FfU0lHTkFU
VVJFOw0KKyAgdm9pZCAqcHRyOw0KICAgY2hhciB0bXBzdHJbMTZdOw0KIA0K
ICAgLyogQ29weSB0aGUgZmlyc3QgMTYgYnl0ZXMgb2YgUk9NICovDQorICBw
dHIgPSBpb3JlbWFwKHBhZGRyICsgMHhjMDAwLCAxNik7DQogICBmb3IgKGk9
MDtpPDE2O2krKykgew0KLSAgICB0bXBzdHJbaV0gPSByZWFkYihwYWRkcisw
eGMwMDAraSk7DQorICAgIHRtcHN0cltpXSA9IHJlYWRiKHB0ciArIGkpOw0K
ICAgfQ0KKyAgaW91bm1hcChwdHIpOw0KIA0KICAgLyogQ2hlY2sgaWYgUFJP
TSBjb250YWlucyBhIHZhbGlkIHN0cmluZyAqLw0KICAgZm9yIChpPTA7KnNp
Z25hdHVyZXNbaV0hPSdcMCc7aSsrKSB7DQpAQCAtMTcxNiwxMCArMTczNiwx
MCBAQA0KICAgICAqLw0KICAgICBpZiAoZW5kIDwgZW50cnkpIHsgICAgICAg
ICAgICAgICAgICAgICAgICAgLyogd3JhcHBlZCBidWZmZXIgKi8NCiAgICAg
ICBsZW4gPSAobHAtPnR4UmluZ01hc2sgLSBlbnRyeSArIDEpICogVFhfQlVG
Rl9TWjsNCi0gICAgICBtZW1jcHlfdG9pbyhscC0+dHhfbWVtY3B5W2VudHJ5
XSwgc2tiLT5kYXRhLCBsZW4pOw0KLSAgICAgIG1lbWNweV90b2lvKGxwLT50
eF9tZW1jcHlbMF0sIHNrYi0+ZGF0YSArIGxlbiwgc2tiLT5sZW4gLSBsZW4p
Ow0KKyAgICAgIG1lbWNweV90b2lvKGxwLT50eF9idWZmW2VudHJ5XSwgc2ti
LT5kYXRhLCBsZW4pOw0KKyAgICAgIG1lbWNweV90b2lvKGxwLT50eF9idWZm
WzBdLCBza2ItPmRhdGEgKyBsZW4sIHNrYi0+bGVuIC0gbGVuKTsNCiAgICAg
fSBlbHNlIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8q
IGxpbmVhciBidWZmZXIgKi8NCi0gICAgICBtZW1jcHlfdG9pbyhscC0+dHhf
bWVtY3B5W2VudHJ5XSwgc2tiLT5kYXRhLCBza2ItPmxlbik7DQorICAgICAg
bWVtY3B5X3RvaW8obHAtPnR4X2J1ZmZbZW50cnldLCBza2ItPmRhdGEsIHNr
Yi0+bGVuKTsNCiAgICAgfQ0KIA0KICAgICAvKiBzZXQgdXAgdGhlIGJ1ZmZl
ciBkZXNjcmlwdG9ycyAqLw0KQEAgLTE3OTUsMTcgKzE4MTUsMTcgQEANCiB7
DQogICBzdHJ1Y3QgZGVwY2FfcHJpdmF0ZSAqbHAgPSAoc3RydWN0IGRlcGNh
X3ByaXZhdGUgKilkZXYtPnByaXY7DQogICB1X2xvbmcgaW9hZGRyID0gZGV2
LT5iYXNlX2FkZHI7DQotICBzdHJ1Y3QgZGVwY2FfaW5pdCAqcCA9IChzdHJ1
Y3QgZGVwY2FfaW5pdCAqKWxwLT5zaF9tZW07DQorICBzdHJ1Y3QgZGVwY2Ff
aW5pdCAqcCA9ICZscC0+aW5pdF9ibG9jazsNCiAgIGludCBpOyANCiANCiAg
IGlmIChkZXBjYV9kZWJ1ZyA+IDEpew0KLSAgICAvKiBDb3B5IHRoZSBzaGFk
b3cgaW5pdF9ibG9jayB0byBzaGFyZWQgbWVtb3J5ICovDQotICAgIG1lbWNw
eV90b2lvKChjaGFyICopbHAtPnNoX21lbSwmbHAtPmluaXRfYmxvY2ssc2l6
ZW9mKHN0cnVjdCBkZXBjYV9pbml0KSk7DQotDQorICAgIC8qIERvIG5vdCBj
b3B5IHRoZSBzaGFkb3cgaW5pdCBibG9jayBpbnRvIHNoYXJlZCBtZW1vcnkg
Ki8NCisgICAgLyogRGVidWdnaW5nIHNob3VsZCBub3QgYWZmZWN0IG5vcm1h
bCBvcGVyYXRpb24hICovDQorICAgIC8qIFRoZSBzaGFkb3cgaW5pdCBibG9j
ayB3aWxsIGdldCBjb3BpZWQgYWNyb3NzIGR1cmluZyBJbml0UmVzdGFydERl
cGNhICovDQogICAgIHByaW50aygiJXM6IGRlcGNhIG9wZW4gd2l0aCBpcnEg
JWRcbiIsZGV2LT5uYW1lLGRldi0+aXJxKTsNCi0gICAgcHJpbnRrKCJEZXNj
cmlwdG9yIGhlYWQgYWRkcmVzc2VzOlxuIik7DQotICAgIHByaW50aygiXHQw
eCVseCAgMHglbHhcbiIsKHVfbG9uZylscC0+cnhfcmluZywgKHVfbG9uZyls
cC0+dHhfcmluZyk7DQotICAgIHByaW50aygiRGVzY3JpcHRvciBhZGRyZXNz
ZXM6XG5SWDogIik7DQorICAgIHByaW50aygiRGVzY3JpcHRvciBoZWFkIGFk
ZHJlc3NlcyAoQ1BVKTpcbiIpOw0KKyAgICBwcmludGsoIiAgICAgICAgMHgl
bHggIDB4JWx4XG4iLCh1X2xvbmcpbHAtPnJ4X3JpbmcsICh1X2xvbmcpbHAt
PnR4X3JpbmcpOw0KKyAgICBwcmludGsoIkRlc2NyaXB0b3IgYWRkcmVzc2Vz
IChDUFUpOlxuUlg6ICIpOw0KICAgICBmb3IgKGk9MDtpPGxwLT5yeFJpbmdN
YXNrO2krKyl7DQogICAgICAgaWYgKGkgPCAzKSB7DQogCXByaW50aygiMHgl
OC44bHggIiwgKGxvbmcpICZscC0+cnhfcmluZ1tpXS5iYXNlKTsNCkBAIC0x
ODE5LDcgKzE4MzksNyBAQA0KICAgICAgIH0NCiAgICAgfQ0KICAgICBwcmlu
dGsoIi4uLjB4JTguOGx4XG4iLCAobG9uZykgJmxwLT50eF9yaW5nW2ldLmJh
c2UpOw0KLSAgICBwcmludGsoIlxuRGVzY3JpcHRvciBidWZmZXJzOlxuUlg6
ICIpOw0KKyAgICBwcmludGsoIlxuRGVzY3JpcHRvciBidWZmZXJzIChEZXZp
Y2UpOlxuUlg6ICIpOw0KICAgICBmb3IgKGk9MDtpPGxwLT5yeFJpbmdNYXNr
O2krKyl7DQogICAgICAgaWYgKGkgPCAzKSB7DQogCXByaW50aygiMHglOC44
eCAgIiwgcmVhZGwoJmxwLT5yeF9yaW5nW2ldLmJhc2UpKTsNCkBAIC0xODMz
LDIxICsxODUzLDIxIEBADQogICAgICAgfQ0KICAgICB9DQogICAgIHByaW50
aygiLi4uMHglOC44eFxuIiwgcmVhZGwoJmxwLT50eF9yaW5nW2ldLmJhc2Up
KTsNCi0gICAgcHJpbnRrKCJJbml0aWFsaXNhdGlvbiBibG9jayBhdCAweCU4
LjhseFxuIixscC0+c2hfbWVtKTsNCi0gICAgcHJpbnRrKCJcdG1vZGU6IDB4
JTQuNHhcbiIscmVhZHcoJnAtPm1vZGUpKTsNCi0gICAgcHJpbnRrKCJcdHBo
eXNpY2FsIGFkZHJlc3M6ICIpOw0KKyAgICBwcmludGsoIkluaXRpYWxpc2F0
aW9uIGJsb2NrIGF0IDB4JTguOGx4KFBoeXMpXG4iLHZpcnRfdG9fcGh5cyhs
cC0+c2hfbWVtKSk7DQorICAgIHByaW50aygiICAgICAgICBtb2RlOiAweCU0
LjR4XG4iLHAtPm1vZGUpOw0KKyAgICBwcmludGsoIiAgICAgICAgcGh5c2lj
YWwgYWRkcmVzczogIik7DQogICAgIGZvciAoaT0wO2k8RVRIX0FMRU4tMTtp
Kyspew0KLSAgICAgIHByaW50aygiJTIuMng6IiwodV9jaGFyKXJlYWRiKCZw
LT5waHlzX2FkZHJbaV0pKTsNCisgICAgICBwcmludGsoIiUyLjJ4OiIsIHAt
PnBoeXNfYWRkcltpXSk7DQogICAgIH0NCi0gICAgcHJpbnRrKCIlMi4yeFxu
IiwodV9jaGFyKXJlYWRiKCZwLT5waHlzX2FkZHJbaV0pKTsNCi0gICAgcHJp
bnRrKCJcdG11bHRpY2FzdCBoYXNoIHRhYmxlOiAiKTsNCisgICAgcHJpbnRr
KCIlMi4yeFxuIiwgcC0+cGh5c19hZGRyW2ldKTsNCisgICAgcHJpbnRrKCIg
ICAgICAgIG11bHRpY2FzdCBoYXNoIHRhYmxlOiAiKTsNCiAgICAgZm9yIChp
PTA7aTwoSEFTSF9UQUJMRV9MRU4gPj4gMyktMTtpKyspew0KLSAgICAgIHBy
aW50aygiJTIuMng6IiwodV9jaGFyKXJlYWRiKCZwLT5tY2FzdF90YWJsZVtp
XSkpOw0KKyAgICAgIHByaW50aygiJTIuMng6IiwgcC0+bWNhc3RfdGFibGVb
aV0pOw0KICAgICB9DQotICAgIHByaW50aygiJTIuMnhcbiIsKHVfY2hhcily
ZWFkYigmcC0+bWNhc3RfdGFibGVbaV0pKTsNCi0gICAgcHJpbnRrKCJcdHJ4
X3JpbmcgYXQ6IDB4JTguOHhcbiIscmVhZGwoJnAtPnJ4X3JpbmcpKTsNCi0g
ICAgcHJpbnRrKCJcdHR4X3JpbmcgYXQ6IDB4JTguOHhcbiIscmVhZGwoJnAt
PnR4X3JpbmcpKTsNCi0gICAgcHJpbnRrKCJkbWFfYnVmZnM6IDB4JTguOGx4
XG4iLGxwLT5kbWFfYnVmZnMpOw0KKyAgICBwcmludGsoIiUyLjJ4XG4iLCBw
LT5tY2FzdF90YWJsZVtpXSk7DQorICAgIHByaW50aygiICAgICAgICByeF9y
aW5nIGF0OiAweCU4Ljh4XG4iLCBwLT5yeF9yaW5nKTsNCisgICAgcHJpbnRr
KCIgICAgICAgIHR4X3JpbmcgYXQ6IDB4JTguOHhcbiIsIHAtPnR4X3Jpbmcp
Ow0KKyAgICBwcmludGsoImJ1ZmZlcnMgKFBoeXMpOiAweCU4LjhseFxuIix2
aXJ0X3RvX3BoeXMobHAtPnNoX21lbSkrbHAtPmJ1ZmZzX29mZnNldCk7DQog
ICAgIHByaW50aygiUmluZyBzaXplOlxuUlg6ICVkICBMb2cyKHJ4UmluZ01h
c2spOiAweCU4Ljh4XG4iLCANCiAJICAgKGludClscC0+cnhSaW5nTWFzayAr
IDEsIA0KIAkgICBscC0+cnhfcmxlbik7DQpAQCAtMjAzMSw2ICsyMDUxLDcg
QEANCiB7DQogICBzdHJ1Y3QgZGVwY2FfcHJpdmF0ZSAqbHAgPSB0aGlzRGVw
Y2EucHJpdjsNCiAgIGlmIChscCkgew0KKyAgICBpb3VubWFwKGxwLT5zaF9t
ZW0pOw0KICNpZmRlZiBDT05GSUdfTUNBICAgICAgDQogICAgIGlmKGxwLT5t
Y2Ffc2xvdCAhPSAtMSkNCiAgICAgICBtY2FfbWFya19hc191bnVzZWQobHAt
Pm1jYV9zbG90KTsNCg==
---1734427118-1221937577-971558165=:1013--

From owner-netdev@oss.sgi.com Sun Oct 15 12:20:11 2000
Received:  by oss.sgi.com id <S553867AbQJOTUB>;
	Sun, 15 Oct 2000 12:20:01 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:4103 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553714AbQJOTTm>;
	Sun, 15 Oct 2000 12:19:42 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA23839; Sun, 15 Oct 2000 23:19:16 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010151919.XAA23839@ms2.inr.ac.ru>
Subject: Re: packet reordering
To:     ahu@ds9a.NL (bert hubert)
Date:   Sun, 15 Oct 2000 23:19:16 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20001014185419.A8295@home.ds9a.nl> from "bert hubert" at Oct 14, 0 08:15:00 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1777
Lines: 53

Hello!

>  this: 2, 1, 4, 3, 6, 5. The problem is that this confuses TCP/IP.

It does not really, provided this tcp/ip is linux-2.4 tcp/ip. 8)8)

Yes, of course, it is problem. That's why I did not recommend
to use per-packet balancing and to use multipath routes instead,
when it is possible.


> Secondly, I was wondering if it would be possible to easily
> make an ingress 'policer' that creates some latency, but does order TCP
> packets on sequence number within that latency.

It is possible, of course. And no doubts, it will be useful.
Only not ingres qdisc, I think, but netfilter plugin. ingres
qdisc is netfilter plugin itself.

But it will not work very well. You will not able to answer
to the question what is this "some latency". If you balance modem links
you will have to select "some latency" bw*dev_queue_len+<some good delta>.
It is big number.

If you balance fast links sort of ethernets, adding latency you will
lose even more. But the worst thing here is reordering in internet.
If the order restorer relies on seq numbers, it will lose due to large scale
reordering on internet.

Actually, link specific encapsulation (sort of gre) could be used
to preserve order on link. Seems, MPPP even does this.


> Would such a beast be possible? If you think it would be worthwile, I'll try
> to code it.

I think the idea of splitting load per-flow at sender side of balanced link
is more productive.


> Thirdly, I tried the normal ingress policer with the script as provided by
> Alexey, but it gave me an error:
> 
> # tc qdisc add dev eth0 handle ffff: ingress
> RTNETLINK answers: No such file or directory
> 
> I think I included everything needed in the kernel.

I do not know, honestly. Ask Jamal.
"Jamal Hadi-Salim" <hadi@nortelnetworks.com>


Alexey

From owner-netdev@oss.sgi.com Sun Oct 15 14:04:03 2000
Received:  by oss.sgi.com id <S553869AbQJOVDx>;
	Sun, 15 Oct 2000 14:03:53 -0700
Received: from 3dyn17.com21.casema.net ([212.64.94.17]:61199 "HELO
        home.ds9a.nl") by oss.sgi.com with SMTP id <S553667AbQJOVD2>;
	Sun, 15 Oct 2000 14:03:28 -0700
Received: (qmail 10870 invoked by uid 500); 15 Oct 2000 21:31:10 -0000
Date:   Sun, 15 Oct 2000 23:31:10 +0200
From:   bert hubert <ahu@ds9a.nl>
To:     netdev@oss.sgi.com
Subject: Re: packet reordering
Message-ID: <20001015233109.A10818@home.ds9a.nl>
Mail-Followup-To: netdev@oss.sgi.com
References: <20001014185419.A8295@home.ds9a.nl> <200010151919.XAA23839@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre4i
In-Reply-To: <200010151919.XAA23839@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Sun, Oct 15, 2000 at 11:19:16PM +0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 2151
Lines: 62

On Sun, Oct 15, 2000 at 11:19:16PM +0400, kuznet@ms2.inr.ac.ru wrote:
> Hello!
> 
> >  this: 2, 1, 4, 3, 6, 5. The problem is that this confuses TCP/IP.
> 
> It does not really, provided this tcp/ip is linux-2.4 tcp/ip. 8)8)
> 
> Yes, of course, it is problem. That's why I did not recommend
> to use per-packet balancing and to use multipath routes instead,
> when it is possible.

For people who want to speed up single tcp/ip sessions, it's not possible. I
have noted in the HOWTO however that Linux is 'smart' about this reordering.

> It is possible, of course. And no doubts, it will be useful.
> Only not ingres qdisc, I think, but netfilter plugin. ingres
> qdisc is netfilter plugin itself.

Ok.

> But it will not work very well. You will not able to answer
> to the question what is this "some latency". If you balance modem links
> you will have to select "some latency" bw*dev_queue_len+<some good delta>.
> It is big number.

It may not be generally useful, true. However, if we equip the reordering
queue with some brains, it might just work. For example, it might have a
fair chance of detecting the 'immediate-next' packet, and send that
directly. For example

2 1
   -> send 1 2, sequence matches

If it doesn't detect such a match, just send after n ms. I'm no router
expert, just thinking out loud.

> Actually, link specific encapsulation (sort of gre) could be used
> to preserve order on link. Seems, MPPP even does this.

This would mean a smarter equaliser and 'merger', but it could be done. I
think this would need a netfilter plugin as well, because I don't expect a
queue to modify its packets?

> > # tc qdisc add dev eth0 handle ffff: ingress
> > RTNETLINK answers: No such file or directory
> > 
> > I think I included everything needed in the kernel.
> 
> I do not know, honestly. Ask Jamal.
> "Jamal Hadi-Salim" <hadi@nortelnetworks.com>

Ok, thanks. I continue to be amazed by the wild possibilities of Linux
routing. 

Regards,

bert hubert

-- 
PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

From owner-netdev@oss.sgi.com Sun Oct 15 15:19:23 2000
Received:  by oss.sgi.com id <S553871AbQJOWTN>;
	Sun, 15 Oct 2000 15:19:13 -0700
Received: from natmail2.webmailer.de ([192.67.198.65]:20433 "EHLO
        post.webmailer.de") by oss.sgi.com with ESMTP id <S553868AbQJOWSz>;
	Sun, 15 Oct 2000 15:18:55 -0700
Received: from frog.athome (pec-117-9.tnt8.s2.uunet.de [149.225.117.9])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id AAA26188;
	Mon, 16 Oct 2000 00:18:52 +0200 (MET DST)
Received: from localhost (hgfelger@localhost)
	by frog.athome (8.9.3/8.9.3) with ESMTP id XAA00322;
	Sun, 15 Oct 2000 23:51:09 +0200
X-Authentication-Warning: frog.athome: hgfelger owned process doing -bs
Date:   Sun, 15 Oct 2000 23:51:02 +0200 (CEST)
From:   Hartwig Felger <hgfelger@hgfelger.de>
X-Sender: hgfelger@frog.athome
Reply-To: hgfelger@hgfelger.de
To:     Henner Eisen <eis@baty.hanse.de>
cc:     netdev@oss.sgi.com
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
In-Reply-To: <oug0m0ilyc.fsf@baty.hanse.de>
Message-ID: <Pine.LNX.4.10.10010151600220.434-100000@frog.athome>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1622
Lines: 44

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salut Henner,
On 13 Oct 2000, Henner Eisen wrote:
>     Hartwig> Hi folks, tryed yesterday to dialin to my server at the
>     Hartwig> office (both server and client are Linux-x86, but server
>     Hartwig> is 2.2.17pre20, whereas the client is 2.4.0test9). As got
> 
> Did you use an actual version of the isdn4k-utils compiled against
> 2.4.0-test9 header files? If not, isdnctrl or ipppd should give you a
> warning messages.

isdn4k-utils.v3.1pre1 against test9, using a gcc-2.95.2 (i.e. egcs)
I now know, that it is not the authentification, because as I had the
wrong user-name it did not crash. So it must be a later step in the
negotiation.

Ok. I now made a new kernel test-10pre3 (made distclean, and just added
the things I need, e.g. isdn, hisax, elsa-microlink-isdn-pci). Also I
typed in the isdnctrl sequence... and it crashed again!

Which setup works for you?
With the test9 i tryed german-msn-by-call, which does not crash (it uses
no auth.), but planet-intercom-by-call does carsh, as well as dialing into
my office.
The debugging is not easy, as it does not sync, before the machine
crashes, and so I do not have logging-information.

Regards hartwig
- -- 
1024D/339FD693 Hartwig Felger <hgfelger@hgfelger.de>
Key fingerprint = FB2F 3EE9 345A D55B 6FF2  0EC1 F5B0 684F 339F D693
For the pulic keys, please visit my page.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE56ibM9bBoTzOf1pMRAorfAKDYe6uasHWzGXy3tx9VD6duI9SDywCeJ0EL
G6S2W0odDUscDaQRy59BWZs=
=ye9n
-----END PGP SIGNATURE-----


From owner-netdev@oss.sgi.com Sun Oct 15 17:28:23 2000
Received:  by oss.sgi.com id <S553679AbQJPA2N>;
	Sun, 15 Oct 2000 17:28:13 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:44451 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S553656AbQJPA1s>;
	Sun, 15 Oct 2000 17:27:48 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id UAA14980;
	Sun, 15 Oct 2000 20:27:34 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id UAA08419;
	Sun, 15 Oct 2000 20:27:34 -0400 (EDT)
Date:   Sun, 15 Oct 2000 20:27:34 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     bert hubert <ahu@ds9a.nl>
cc:     netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru, devik@server.cdi.cz
Subject: Re: packet reordering
In-Reply-To: <20001015233109.A10818@home.ds9a.nl>
Message-ID: <Pine.GSO.4.20.0010151959190.8400-100000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 2726
Lines: 73



On Sun, 15 Oct 2000, bert hubert wrote:

> > It does not really, provided this tcp/ip is linux-2.4 tcp/ip. 8)8)
> > 
> > Yes, of course, it is problem. That's why I did not recommend
> > to use per-packet balancing and to use multipath routes instead,
> > when it is possible.
> 
> For people who want to speed up single tcp/ip sessions, it's not possible. I
> have noted in the HOWTO however that Linux is 'smart' about this reordering.
> 

Probably _the only OS today_ with these features, thanks to the good work
by Alexey.

> > It is possible, of course. And no doubts, it will be useful.
> > Only not ingres qdisc, I think, but netfilter plugin. ingres
> > qdisc is netfilter plugin itself.
> 
> Ok.
> 

Actually it can be done at the ingress qdisc; i just question its
usefulness. 
Infact devik@server.cdi.cz had a patch for the ingress qdisc (my memory is
hazy at the moment, maybe he had an alternative). 

> > But it will not work very well. You will not able to answer
> > to the question what is this "some latency". If you balance modem links
> > you will have to select "some latency" bw*dev_queue_len+<some good delta>.
> > It is big number.
> 
> It may not be generally useful, true. However, if we equip the reordering
> queue with some brains, it might just work. For example, it might have a
> fair chance of detecting the 'immediate-next' packet, and send that
> directly. For example
> 
> 2 1
>    -> send 1 2, sequence matches
> 
> If it doesn't detect such a match, just send after n ms. I'm no router
> expert, just thinking out loud.
> 

To re-iterate what Alexey points out (look at his mail again on this):
Where do you draw the line? How long timewise or packet-count-wise do
you wait? those are the hard questions you have to answer. And they are
hard because of the non-determinism of the re-ordering. 
I have experimented with schemes like these, result: CPU utilization goes
up 1) as the number of flows increase 2) as the bandwidth of the flow goes
up. Very easily you hit the 100% CPU utilization mark even on SMP.
I think we have come a long way from the days Van Jacobson waved his hands 
in the air and proclaimed you can have re-ordering of upto three packets
on the intenet (No offense to VJ, I understand the number 3 was based on a
study actually). Making any assumptions on bounds is where the core of the
issue is -- you cant.


> > > # tc qdisc add dev eth0 handle ffff: ingress
> > > RTNETLINK answers: No such file or directory
> > > 
> > > I think I included everything needed in the kernel.
> > 

You need to provide more information (kernel, config etc). 
Questions like these should probably go on the linux-diffserv mailing
list; a few people would respond.

cheers,
jamal


From owner-netdev@oss.sgi.com Mon Oct 16 08:00:51 2000
Received:  by oss.sgi.com id <S553786AbQJPPAl>;
	Mon, 16 Oct 2000 08:00:41 -0700
Received: from dynamic14.pm01.santa-cruz.best.com ([209.157.50.14]:260 "EHLO
        localhost.localdomain") by oss.sgi.com with ESMTP
	id <S553782AbQJPPAe>; Mon, 16 Oct 2000 08:00:34 -0700
Received: (from shaeffer@localhost)
	by localhost.localdomain (8.11.0/8.11.0) id e9GF2Rw01005
	for netdev@oss.sgi.com; Mon, 16 Oct 2000 08:02:27 -0700
Date:   Mon, 16 Oct 2000 08:02:27 -0700
From:   Karen Shaeffer <shaeffer@best.com>
To:     netdev@oss.sgi.com
Subject: PXE compliant NIC
Message-ID: <20001016080227.A961@anode.best.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 193
Lines: 9

Hi folks,

Does anyone know of a NIC that is PXE compliant *out of the box*?

TIA,
-- 
 Karen Shaeffer
 Neuralscape; Santa Cruz, Ca. 95060
 shaeffer@neuralscape.com  http://www.neuralscape.com

From owner-netdev@oss.sgi.com Mon Oct 16 10:08:22 2000
Received:  by oss.sgi.com id <S553690AbQJPRIM>;
	Mon, 16 Oct 2000 10:08:12 -0700
Received: from 24.69.164.40.on.wave.home.com ([24.69.164.40]:64500 "EHLO
        odysseus.cybertor.com") by oss.sgi.com with ESMTP
	id <S553663AbQJPRH5>; Mon, 16 Oct 2000 10:07:57 -0700
Received: from cybertor.com (ntorys@localhost [127.0.0.1])
	by odysseus.cybertor.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA22536
	for <netdev@oss.sgi.com>; Mon, 16 Oct 2000 13:07:50 -0400
From:   ntorys@cybertor.com
Message-Id: <200010161707.NAA22536@odysseus.cybertor.com>
X-Authentication-Warning: odysseus.cybertor.com: Host ntorys@localhost [127.0.0.1] claimed to be cybertor.com
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To:     netdev@oss.sgi.com
Subject: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 16 Oct 2000 13:07:50 -0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1569
Lines: 45

Hi there,

You may be aware of this already, but I thought I will let you know
of my observation anyway.

I have been running kernel 2.4.0-testn since their release. I have also
been experiencing download failures, while I was mirroring Debian's
distribution. I did not pay attention, when my problems started.

I tried everything, from network adapters to different makes, to
machine setups, I thought that somewhere along the line I messed something
up, I was even blaming my provider.

Anyway, yesterday suddenly it struck me; I decided to try kernel source 2.2.17
from Debian's 2.2 (Potato), and suddenly things started to work again, not one 
failure.

Here is the example of the messages:
Failure on 'RETR dists/potato/main/binary-arm/interpreters/gforth_0.4.9.1999061
7-1.deb' command
Failed to get dists/potato/main/binary-arm/interpreters/gforth_0.4.9.19990617-1
.deb: timed out
Failed to get file timed out
Cannot open data socket
I actually had another problem, but it went away when I switched to 3COM 
adapters, my machine
was locking up when I was transferring more that 300MB of data from it.

I hope you may find this information of some use.

The reason, why I am running 2.4.0 is for my sound card, and the support for 
the Athlon
mother board.

Regards,


-- 
Nick Torys      - Cybertor Enterprises Ltd. 
                - Markham, Ont, Canada
                - Phone (905) 471-0600
                - ntorys@cybertor.com
                - Instrumentation for Process Control Industry
                                                                


From owner-netdev@oss.sgi.com Mon Oct 16 15:03:36 2000
Received:  by oss.sgi.com id <S553678AbQJPWD0>;
	Mon, 16 Oct 2000 15:03:26 -0700
Received: from kogge.hanse.de ([192.76.134.17]:54278 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553652AbQJPWDA>;
	Mon, 16 Oct 2000 15:03:00 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id AAA30516;
	Tue, 17 Oct 2000 00:07:29 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id XAA20597;
	Mon, 16 Oct 2000 23:16:49 +0200
Date:   Mon, 16 Oct 2000 23:16:49 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200010162116.XAA20597@baty.hanse.de>
To:     hgfelger@hgfelger.de
CC:     netdev@oss.sgi.com, i4ldeveloper@listserv.isdn4linux.de
In-reply-to: <Pine.LNX.4.10.10010151600220.434-100000@frog.athome> (message
	from Hartwig Felger on Sun, 15 Oct 2000 23:51:02 +0200 (CEST))
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
References:  <Pine.LNX.4.10.10010151600220.434-100000@frog.athome>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1826
Lines: 43


Hi,

>>>>> "Hartwig" == Hartwig Felger <hgfelger@hgfelger.de> writes:

    >>  Did you use an actual version of the isdn4k-utils compiled
    >> against 2.4.0-test9 header files? If not, isdnctrl or ipppd
    >> should give you a warning messages.

    Hartwig> isdn4k-utils.v3.1pre1 against test9, using a gcc-2.95.2

o.k., just wanted to be sure because I observed some minor instability
problems when the isdn-related header files changed some -testX ago.
Otherwise, I did not experience any problems.


    Hartwig> Ok. I now made a new kernel test-10pre3 (made distclean,
    Hartwig> and just added the things I need, e.g. isdn, hisax,
    Hartwig> elsa-microlink-isdn-pci). Also I typed in the isdnctrl
    Hartwig> sequence... and it crashed again!

    Hartwig> Which setup works for you?  With the test9 i tryed
    Hartwig> german-msn-by-call, which does not crash (it uses no
    Hartwig> auth.), but planet-intercom-by-call does carsh, as well
    Hartwig> as dialing into my office.  The debugging is not easy, as
    Hartwig> it does not sync, before the machine crashes, and so I do
    Hartwig> not have logging-information.

As it occurs only with certain providers, it might be compression related.
Different providers might support different kinds of compression. Thus,
the problem might only occur with certain providers.
In order to get further insights (and maybe for beeing able to re-produce
the problem):

- Which isdn_ppp compression support is configured in your kernel?
- Which isdn_ppp compression is configured for your ipppd?
- Can you determine form the syslog (`debug' option of ipppd) what
  compression was negotiated with the different providers? 
- For the providers which crash: Try to switch on or off compression
  by means of the ipppd command line or ipppd´s options file.

Henner


From owner-netdev@oss.sgi.com Tue Oct 17 07:24:34 2000
Received:  by oss.sgi.com id <S553743AbQJQOYN>;
	Tue, 17 Oct 2000 07:24:13 -0700
Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:7266 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S553694AbQJQOXu>;
	Tue, 17 Oct 2000 07:23:50 -0700
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 13lXgU-0004gT-00
	for netdev@oss.sgi.com; Tue, 17 Oct 2000 15:25:42 +0100
Received: from california.iwk.dk
	([195.24.22.204] helo=mail.iwk.dk ident=qmailr)
	by the-village.bc.nu with smtp (Exim 2.12 #1)
	id 13lXaC-0004fk-00
	for alan@lxorguk.ukuu.org.uk; Tue, 17 Oct 2000 15:19:12 +0100
Received: (qmail 24971 invoked from network); 17 Oct 2000 14:12:10 -0000
Received: from firewall.i-data.com (HELO hashbang.org) (195.24.22.194)
  by california.iwk.dk with SMTP; 17 Oct 2000 14:12:10 -0000
Message-ID: <39EC5F50.9C47DF10@hashbang.org>
Date:   Tue, 17 Oct 2000 16:16:48 +0200
From:   Peter Loje Hansen <peter@hashbang.org>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.17-RAID i686)
X-Accept-Language: en, da
MIME-Version: 1.0
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Can ping interface after it's down on Linux > 2.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On two machines running 2.2.17 and one running 2.4-pre9-rest9 I have observed
that it is possible to ping an interface after it has been brought down.

On 2.0.38 I get "Network is unreachable"

Is this a bug or a feature?

Tomorrow we are going to take a new Compaq server into operation so I configured
eth0 with the same ip address as the old server and configured eth1 to be on
another network in order to do the final rsync tonight:

eth0: 172.16.52.32/255.255.255.0
eth1: 172.17.136.1/255.255.0.0 gw 172.17.0.254

I then took eth0 down connected the cables and could ping 172.16.52.32 thinking
that is was the old server I was pinging via eth1. When I telnetted to the
address I got the login prompt from the new server. arp -a showed nothing
interesting. I could reproduce this on another 2.2.17 machine.

pinging 172.16.52.31 (or any different from .32) gives "Network is unreachable".

The ip address of eth1 was also "pingable" after it was downed.

If I also took lo down the ping's for 127.0.0.1, 172.16.52.32 or 172.17.136.1
just hangs.

Occasionally I see something along "error fetching interface information" from
ifconfig on 2.2.17.

Most devices are eepro100.

Many regards
Peter

-- 
Peter L. Hansen
LASAT Networks A/S
pha@lasat.com / peter@hashbang.org


From owner-netdev@oss.sgi.com Tue Oct 17 07:30:54 2000
Received:  by oss.sgi.com id <S553750AbQJQOae>;
	Tue, 17 Oct 2000 07:30:34 -0700
Received: from natmail2.webmailer.de ([192.67.198.65]:4849 "EHLO
        post.webmailer.de") by oss.sgi.com with ESMTP id <S553691AbQJQOa2>;
	Tue, 17 Oct 2000 07:30:28 -0700
Received: from frog.athome (pec-104-6.tnt5.s2.uunet.de [149.225.104.6])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id QAA16015;
	Tue, 17 Oct 2000 16:30:25 +0200 (MET DST)
Received: from localhost (hgfelger@localhost)
	by frog.athome (8.9.3/8.9.3) with ESMTP id QAA00563;
	Tue, 17 Oct 2000 16:29:54 +0200
X-Authentication-Warning: frog.athome: hgfelger owned process doing -bs
Date:   Tue, 17 Oct 2000 16:29:46 +0200 (CEST)
From:   Hartwig Felger <hgfelger@hgfelger.de>
X-Sender: hgfelger@frog.athome
Reply-To: hgfelger@hgfelger.de
To:     Henner Eisen <eis@baty.hanse.de>
cc:     netdev@oss.sgi.com, i4ldeveloper@listserv.isdn4linux.de
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
In-Reply-To: <200010162116.XAA20597@baty.hanse.de>
Message-ID: <Pine.LNX.4.10.10010171620350.554-100000@frog.athome>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salut Henner,
On Mon, 16 Oct 2000, Henner Eisen wrote:
>     Hartwig> isdn4k-utils.v3.1pre1 against test9, using a gcc-2.95.2
> o.k., just wanted to be sure because I observed some minor instability
> problems when the isdn-related header files changed some -testX ago.
> Otherwise, I did not experience any problems.
>     Hartwig> not have logging-information.
> 
> As it occurs only with certain providers, it might be compression related.
That's it - I tryed to switch-off some before, but forgot to disable
bsdcomp and ccp. The CCP is the bad thing!
> - Can you determine form the syslog (`debug' option of ipppd) what
>   compression was negotiated with the different providers? 
> - For the providers which crash: Try to switch on or off compression
>   by means of the ipppd command line or ipppd´s options file.
Does anybody know, where ccp is implemented (ipppd vs. kernel). Best would
be, if somebody tells me, which source-file it is, then I may dig a bit
further.
After adding "noccp" everything works again for me.
Is there a way, to make ipppd put out the logging to stderr, instead of
piping it to the syslog, as it is always too late to get piped to the
other process, and if the kernel hangs completely, the unsynced part of
the files is not recoverable.

Thanks hartwig :-)

- -- 
1024D/339FD693 Hartwig Felger <hgfelger@hgfelger.de>
Key fingerprint = FB2F 3EE9 345A D55B 6FF2  0EC1 F5B0 684F 339F D693
For the pulic keys, please visit my page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE57GJi9bBoTzOf1pMRAoo8AKDp4s+dTFeEtwhbrcgyKDSU96c8qQCgzy4l
pr9G7HQrwLzxWiUn054Tyos=
=3HuE
-----END PGP SIGNATURE-----


From owner-netdev@oss.sgi.com Tue Oct 17 11:28:06 2000
Received:  by oss.sgi.com id <S553660AbQJQS14>;
	Tue, 17 Oct 2000 11:27:56 -0700
Received: from kogge.hanse.de ([192.76.134.17]:8708 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553651AbQJQS1j>;
	Tue, 17 Oct 2000 11:27:39 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id UAA02730;
	Tue, 17 Oct 2000 20:27:31 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id TAA23474;
	Tue, 17 Oct 2000 19:15:33 +0200
Date:   Tue, 17 Oct 2000 19:15:33 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200010171715.TAA23474@baty.hanse.de>
To:     hgfelger@hgfelger.de
CC:     netdev@oss.sgi.com, i4ldeveloper@listserv.isdn4linux.de
In-reply-to: <Pine.LNX.4.10.10010171620350.554-100000@frog.athome> (message
	from Hartwig Felger on Tue, 17 Oct 2000 16:29:46 +0200 (CEST))
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
References:  <Pine.LNX.4.10.10010171620350.554-100000@frog.athome>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "Hartwig" == Hartwig Felger <hgfelger@hgfelger.de> writes:

    Hartwig> That's it - I tryed to switch-off some before, but forgot
    Hartwig> to disable bsdcomp and ccp. The CCP is the bad thing!

Does `-bsdcomp' alone already fix the problem?

Does the problem only occur with demand dial-up or even if you start
the connection manually (isdnctrl dial ippp0)?

    Hartwig> Does anybody know, where ccp is implemented (ipppd
    Hartwig> vs. kernel).

The classical pppd approach is that the kernel just passes the ccp
frames to user space such that pppd implements the protocol (and just
controls the compressor by means of some ioctls). I guess when LCS
compression support was added, it was necessary to handle certain
parts of ccp inside the kernel, but I´m not familar with the details.

    Hartwig> Best would be, if somebody tells me, which
    Hartwig> source-file it is, then I may dig a bit further.  After

drivers/net/isdn/isdn_ppp.c for the kernel. In the [i]pppd source, it
should be in ccp.c.

    Hartwig> adding "noccp" everything works again for me.  Is there a
    Hartwig> way, to make ipppd put out the logging to stderr, instead

As far as I know, there isn´t (beside editing the ipppd sources ;).
But it should be possible to let the ippp kernel modules writing
debugging messages. Try setting the kdebug option of ipppd to 0xff
and do (as root) `klogkonsole -l 7 -r 1' before you start the connection
and whatch the kernel's debug messages on virtual console 1.

Ss you can reproduce the problem with a Linux 2.2.x peer server
in your office (which does not crash), it should also be possible to 
additinally capture the (syslog-based) log at the server side.

Henner

From owner-netdev@oss.sgi.com Tue Oct 17 19:19:22 2000
Received:  by oss.sgi.com id <S553673AbQJRCTC>;
	Tue, 17 Oct 2000 19:19:02 -0700
Received: from Cantor.suse.de ([194.112.123.193]:41487 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553648AbQJRCS6>;
	Tue, 17 Oct 2000 19:18:58 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id A25D71E3A7; Wed, 18 Oct 2000 04:18:55 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id DDECA3E460; Wed, 18 Oct 2000 04:18:54 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 0EA462F300; Wed, 18 Oct 2000 04:18:54 +0200 (MEST)
Date:   Wed, 18 Oct 2000 04:18:54 +0200
From:   Andi Kleen <ak@suse.de>
To:     philb@gnu.org
Cc:     net-tools@lina.inka.de, netdev@oss.sgi.com
Subject: Add nameif to net-tools
Message-ID: <20001018041853.A10118@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


Hallo,

I wrote a small tool called nameif some time ago. It names network interfaces
based on a file containing MAC addresses. This way you can maintain a stable
network configuration even when the kernel changes probe orders
(e.g. when modules are loaded in a different order or the kernel version
changes). Basically it does the same job as scsidev, only for network
interfaces. 

I appended the simple file for reference. There is no man page yet, but
I'll write one. 

Would anyone complain when I add it to net-tools ? 


-Andi


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="nameif.c"

/* 
 * Name Interfaces based on MAC address.
 * Writen 2000 by Andi Kleen.
 * Subject to the Gnu Public License, version 2.  
 */ 
#define _GNU_SOURCE
#include <stdio.h>
#include <getopt.h>
#include <sys/syslog.h>
#include <errno.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <stdarg.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <net/if.h>
#include <linux/sockios.h>
#include <errno.h>

const char default_conf[] = "/etc/mactab"; 
const char *fname = default_conf; 
int use_syslog; 
int ctl_sk = -1; 

void err(char *msg) 
{ 
	if (use_syslog) { 
		syslog(LOG_ERR,"%s: %m", msg); 
	} else { 
		perror(msg); 
	} 
	exit(1); 
}

void complain(char *fmt, ...) 
{ 
	va_list ap;
	va_start(ap,fmt);
	if (use_syslog) { 
		vsyslog(LOG_ERR,fmt,ap);
	} else {
		vfprintf(stderr,fmt,ap); 
	}
	va_end(ap); 
	exit(1);
} 

void warning(char *fmt, ...) 
{ 
	va_list ap;
	va_start(ap,fmt);
	if (use_syslog) { 
		vsyslog(LOG_ERR,fmt,ap);
	} else {
		vfprintf(stderr,fmt,ap); 
	}
	va_end(ap); 
} 

int parsemac(char *str, unsigned char *mac)
{ 
	char *s; 
	while ((s = strsep(&str, ":")) != NULL) { 
		unsigned byte;
		sscanf(s,"%x", &byte);
		if (byte > 0xff) 
			return -1;
		*mac++ = byte; 
	}  
	return 0;
} 

void *xmalloc(unsigned sz)
{ 
	void *p = calloc(sz,1);
	if (!p) complain("out of memory"); 
	return p; 
} 

void opensock(void)
{
	if (ctl_sk < 0) 
		ctl_sk = socket(PF_INET,SOCK_DGRAM,0); 
}

#ifndef ifr_newname
#define ifr_newname ifr_ifru.ifru_slave
#endif

int  setname(char *oldname, char *newname)
{
	struct ifreq ifr;
	opensock(); 
	memset(&ifr,0,sizeof(struct ifreq));
	strcpy(ifr.ifr_name, oldname); 
	strcpy(ifr.ifr_newname, newname); 
	return ioctl(ctl_sk, SIOCSIFNAME, &ifr);
}

int getmac(char *name, unsigned char *mac)
{
	int r;
	struct ifreq ifr;
	opensock(); 
	memset(&ifr,0,sizeof(struct ifreq));
	strcpy(ifr.ifr_name, name); 
	r = ioctl(ctl_sk, SIOCGIFHWADDR, &ifr);
	memcpy(mac, ifr.ifr_hwaddr.sa_data, 6); 
	return r; 
}

struct change { 
	struct change *next,**pprev;
	char ifname[IFNAMSIZ+1];
	unsigned char mac[6];
}; 
struct change *clist;

struct change *lookupmac(unsigned char *mac) 
{ 
	struct change *ch;
	for (ch = clist;ch;ch = ch->next) 
		if (!memcmp(ch->mac, mac, 6))
			return ch;
	return NULL; 
} 

int addchange(char *p, struct change *ch, char *pos)
{
	if (strchr(ch->ifname, ':'))
		warning("alias device %s at %s probably has no mac", 
			ch->ifname, pos); 
	if (parsemac(p,ch->mac) < 0) 
		complain("cannot parse MAC `%s' at %s", p, pos); 
	if (clist) 
		clist->pprev = &ch->next;
	ch->next = clist;
	ch->pprev = &clist;
	clist = ch;
	return 0; 
}

void readconf(void)
{
	char *line; 
	size_t linel; 
	int linenum; 
	FILE *ifh;
	char *p;
	int n;

	ifh = fopen(fname, "r");
	if (!ifh) 
		complain("opening configuration file %s: %s",fname,strerror(errno)); 

	line = NULL; 
	linel = 0;
	linenum = 1; 
	while (getdelim(&line, &linel, '\n', ifh) > 0) {
		struct change *ch = xmalloc(sizeof(struct change)); 
		char pos[20]; 

		sprintf(pos, "line %d", linenum); 

		if ((p = strchr(line,'#')) != NULL)
			*p = '\0';
		p = line; 
		while (isspace(*p))
			++p; 
		if (*p == '\0')
			continue; 
		n = strcspn(p, " \t"); 
		if (n > IFNAMSIZ) 
			complain("interface name too long at line %d", line);  
		memcpy(ch->ifname, p, n); 
		ch->ifname[n] = 0; 
		p += n; 
		p += strspn(p, " \t"); 
		n = strspn(p, "0123456789ABCDEFabcdef:"); 
		p[n] = 0; 
		addchange(p, ch, pos);
		linenum++;
	}   
	fclose(ifh); 
}

struct option lopt[] = { 
	{"syslog", 0, NULL, 's' },
	{"config-file", 1, NULL, 'c' },
	{"help", 0, NULL, '?' }, 
	{NULL}, 
}; 

void usage(void)
{
	fprintf(stderr, "usage: nameif [-c configurationfile] [-s] {ifname macaddress}"); 
	exit(1); 
}

int main(int ac, char **av) 
{ 
	FILE *ifh; 
	char *p;
	int n;
	int linenum; 
	char *line;
	size_t linel;

	for (;;) {
		int c = getopt_long(ac,av,"c:s",lopt,NULL);
		if (c == -1) break;
		switch (c) { 
		default:
		case '?':
			usage(); 
		case 'c':
			fname = optarg;
			break;
		case 's':
			use_syslog = 1;
			break;
		}
	}

	if (use_syslog) 
		openlog("nameif",0,LOG_LOCAL0);

	while (optind < ac) { 
		struct change *ch = xmalloc(sizeof(struct change)); 
		char pos[30];

		if ((ac-optind) & 1) 
			usage();
		if (strlen(av[optind])-1>IFNAMSIZ) 
			complain("interface `%s' too long", av[optind]);
		strcpy(ch->ifname, av[optind]); 
		optind++; 
		sprintf(pos,"argument %d",optind); 
		addchange(av[optind], ch, pos); 
		optind++; 
	} 

	if (!clist || fname != default_conf) 
		readconf(); 

	ifh = fopen("/proc/net/dev", "r"); 
	if (!ifh)  complain("open of /proc/net/dev: %s", strerror(errno)); 

        linenum = 0;
        while (getdelim(&line, &linel, '\n', ifh) > 0) {
		struct change *ch; 
		unsigned char mac[6];

		if (linenum++ < 2) 
			continue;
		p = line; 
		while (isspace(*p)) 
			++p;
		n = strcspn(p, ": \t");  
		p[n] = 0; 
		if (getmac(p, mac) < 0) 
			continue;
		ch = lookupmac(mac); 
		if (!ch) 
			continue;
		*ch->pprev = ch->next;
		if (strcmp(p, ch->ifname)) { 
			if (setname(p, ch->ifname) < 0) 
				complain("cannot change name of %s to %s: %s",
						p, ch->ifname, strerror(errno)); 
		} 
		free(ch);
	} 
	fclose(ifh); 
	
	while (clist) { 
		struct change *ch = clist;
		clist = clist->next;
		warning("interface '%s' not found", ch->ifname); 
		free(ch); 
	}

	if (use_syslog)
		closelog();
	return 0;
} 


--cWoXeonUoKmBZSoM--

From owner-netdev@oss.sgi.com Tue Oct 17 19:59:23 2000
Received:  by oss.sgi.com id <S553696AbQJRC7N>;
	Tue, 17 Oct 2000 19:59:13 -0700
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:36110 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S553688AbQJRC65>;
	Tue, 17 Oct 2000 19:58:57 -0700
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.9.3) with ESMTP id UAA26241;
	Tue, 17 Oct 2000 20:51:29 -0700
Message-ID: <39ED1E41.37F6A10C@candelatech.com>
Date:   Tue, 17 Oct 2000 20:51:29 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andi Kleen <ak@suse.de>
CC:     philb@gnu.org, net-tools@lina.inka.de, netdev@oss.sgi.com
Subject: Re: Add nameif to net-tools
References: <20001018041853.A10118@gruyere.muc.suse.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Andi Kleen wrote:
> 
> Hallo,
> 
> I wrote a small tool called nameif some time ago. It names network interfaces
> based on a file containing MAC addresses. This way you can maintain a stable
> network configuration even when the kernel changes probe orders
> (e.g. when modules are loaded in a different order or the kernel version
> changes). Basically it does the same job as scsidev, only for network
> interfaces.
> 
> I appended the simple file for reference. There is no man page yet, but
> I'll write one.
> 
> Would anyone complain when I add it to net-tools ?
> 
> -Andi

Sounds good to me...It'll help me test my hash code :)

Ben


-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Tue Oct 17 20:03:23 2000
Received:  by oss.sgi.com id <S553700AbQJRDDO>;
	Tue, 17 Oct 2000 20:03:14 -0700
Received: from lina.inka.de ([212.227.16.17]:65082 "EHLO matrix.inka.de")
	by oss.sgi.com with ESMTP id <S553692AbQJRDDD>;
	Tue, 17 Oct 2000 20:03:03 -0700
Received: from calista.inka.de (mail@calista.eckenfels.net [10.0.0.3])
	by matrix.inka.de (8.9.3/8.9.2) with ESMTP id FAA26824;
	Wed, 18 Oct 2000 05:01:46 +0200
Received: from ecki by calista.inka.de with local (Exim 3.16 #1 (Debian))
	id 13ljU8-0006k8-00; Wed, 18 Oct 2000 05:01:44 +0200
Date:   Wed, 18 Oct 2000 05:01:44 +0200
To:     Andi Kleen <ak@suse.de>
Cc:     philb@gnu.org, net-tools@lina.inka.de, netdev@oss.sgi.com
Subject: Re: Add nameif to net-tools
Message-ID: <20001018050144.A24975@lina.inka.de>
References: <20001018041853.A10118@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001018041853.A10118@gruyere.muc.suse.de>; from ak@suse.de on Wed, Oct 18, 2000 at 04:18:54AM +0200
From:   Bernd Eckenfels <ecki@lina.inka.de>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Wed, Oct 18, 2000 at 04:18:54AM +0200, Andi Kleen wrote:
> Would anyone complain when I add it to net-tools ? 

thats fine, could use net-lib or indepened mac parsing but otherwise..

Greetings
Bernd
-- 
  (OO)      -- Bernd_Eckenfels@Wendelinusstrasse39.76646Bruchsal.de --
 ( .. )  ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
  o--o     *plush*  2048/93600EFD  eckes@irc  +497257930613  BE5-RIPE
(O____O)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

From owner-netdev@oss.sgi.com Tue Oct 17 22:40:34 2000
Received:  by oss.sgi.com id <S553681AbQJRFkY>;
	Tue, 17 Oct 2000 22:40:24 -0700
Received: from mail.uni-kl.de ([131.246.137.52]:36814 "EHLO mail.uni-kl.de")
	by oss.sgi.com with ESMTP id <S553659AbQJRFkI>;
	Tue, 17 Oct 2000 22:40:08 -0700
Received: from mail1.itwm.uni-kl.de (mail@mail1.itwm.uni-kl.de [131.246.191.170])
	by mail.uni-kl.de (8.11.0/8.11.0) with ESMTP id e9I5e5w10418;
	Wed, 18 Oct 2000 07:40:05 +0200 (MET DST)
Received: from ms1.itwm.uni-kl.de ([131.246.191.1] ident=mail)
	by mail1.itwm.uni-kl.de with esmtp (Exim 2.01 #1)
	id 13llxN-0007rl-00; Wed, 18 Oct 2000 07:40:05 +0200
Received: from alcatraz26.wohnheim.uni-kl.de ([131.246.107.35] helo=fred)
	by ms1.itwm.uni-kl.de with smtp (Exim 2.01 #1)
	id 13llxN-00032T-00; Wed, 18 Oct 2000 07:40:05 +0200
Message-ID: <00ff01c038c5$de0a8cc0$1102a8c0@fred>
From:   "Peter Zimmer" <zimmer@itwm.uni-kl.de>
To:     <netdev@oss.sgi.com>, <davem@redhat.com>
Subject: Weird INterfaces
Date:   Wed, 18 Oct 2000 07:40:04 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi!
I'm in serious trouble right now.
I built a firewall with the 2.2.x kernel (with ipchains + masquerading
+ ipip tunnel).
If I try to connect to my firewall from another computer(inner or outer
net) , sometimes (50%, what else??) the 'wrong' interface answers (my
firewall detects packets for the ethX on ethY). Now, there comes the
strange thing: When I connect from the firewall to any other computer
(inner or outer net), there's the same behaviour.
The same things happen if I clean out the ipchains tables.
e.g. the only route to net 192.168.1.0 is through Interface eth1, but
sometimes the firewall computer tries to send packets to this net through
eth0.
It occurs only if the connections are 'expired', if there's no
connection to or from firewall shown in arp tables anymore.
When I set the arp tables on the other machines by hand, there's no
problem at all, but I can't do it, too many computers.
I think it has something to do with the fact, that the 2 logical nets
(inner and outer) are not divided physical(the packets are traversed
through the same switches), and the NIC'S in the firewall are identical.
(Intel EEPRO100 (with GD82559 chip), formerly SMC Etherpower 100(with
83c170 chip), but same behaviour with these)
My kernel versions are 2.2.16 on the one firewall and 2.2.17 on the
other (the tunnel is between these two)

Thanx in advance,

    Peter Zimmer




From owner-netdev@oss.sgi.com Wed Oct 18 07:10:28 2000
Received:  by oss.sgi.com id <S553734AbQJROKI>;
	Wed, 18 Oct 2000 07:10:08 -0700
Received: from pop3.galileo.co.il ([199.203.130.130]:11698 "EHLO
        galileo5.galileo.co.il") by oss.sgi.com with ESMTP
	id <S553708AbQJROJo>; Wed, 18 Oct 2000 07:09:44 -0700
Received: from galileo.co.il (rabeeh@linux2.galileo.co.il [10.2.40.2])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id QAA13390
	for <netdev@oss.sgi.com>; Wed, 18 Oct 2000 16:09:27 +0200 (GMT-2)
Message-ID: <39EDA088.581E102E@galileo.co.il>
Date:   Wed, 18 Oct 2000 16:07:20 +0300
From:   Rabeeh Khoury <rabeeh@galileo.co.il>
Reply-To: rabeeh@galileo.co.il
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev <netdev@oss.sgi.com>
Subject: ARP with FrameRelay
Content-Type: multipart/mixed;
 boundary="------------41E0FFB494C22B8077B78EEC"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This is a multi-part message in MIME format.
--------------41E0FFB494C22B8077B78EEC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi All,


I'm trying to set an ARP entry in the kernel ARP table for a framerelay
link using the following command :


arp -v -H dlci -i dlci00 -s 192.168.10.2  50

but I always get segmentation fault.

Did any one encounter such a problem ?
P.S. I'm running RedHat 6.2 with kernel 2.2  versus mips embedded system
kernel 2.2.14, and the ARP didn't work on both platforms.

Regards,
Rabeeh

--------------41E0FFB494C22B8077B78EEC
Content-Type: text/x-vcard; charset=us-ascii;
 name="rabeeh.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Rabeeh Khoury
Content-Disposition: attachment;
 filename="rabeeh.vcf"

begin:vcard 
n:Khoury;Rabeeh
x-mozilla-html:FALSE
org:Galileo Technology;Software Department
adr:;;;;;;
version:2.1
email;internet:rabeeh@galileo.co.il
title:Development Engineer
x-mozilla-cpt:;-31712
fn:Rabeeh Khoury
end:vcard

--------------41E0FFB494C22B8077B78EEC--


From owner-netdev@oss.sgi.com Wed Oct 18 16:16:55 2000
Received:  by oss.sgi.com id <S553763AbQJRXQq>;
	Wed, 18 Oct 2000 16:16:46 -0700
Received: from natmail2.webmailer.de ([192.67.198.65]:45965 "EHLO
        post.webmailer.de") by oss.sgi.com with ESMTP id <S553755AbQJRXQX>;
	Wed, 18 Oct 2000 16:16:23 -0700
Received: from frog.athome (pec-1-90.tnt1.s2.uunet.de [149.225.1.90])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id BAA20455;
	Thu, 19 Oct 2000 01:16:20 +0200 (MET DST)
Received: from localhost (hgfelger@localhost)
	by frog.athome (8.9.3/8.9.3) with ESMTP id BAA00741;
	Thu, 19 Oct 2000 01:16:06 +0200
X-Authentication-Warning: frog.athome: hgfelger owned process doing -bs
Date:   Thu, 19 Oct 2000 01:16:00 +0200 (CEST)
From:   Hartwig Felger <hgfelger@hgfelger.de>
X-Sender: hgfelger@frog.athome
Reply-To: hgfelger@hgfelger.de
To:     Henner Eisen <eis@baty.hanse.de>
cc:     netdev@oss.sgi.com, i4ldeveloper@listserv.isdn4linux.de
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
In-Reply-To: <200010171715.TAA23474@baty.hanse.de>
Message-ID: <Pine.LNX.4.10.10010190028170.364-100000@frog.athome>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salut Henner,
On Tue, 17 Oct 2000, Henner Eisen wrote:
> >>>>> "Hartwig" == Hartwig Felger <hgfelger@hgfelger.de> writes:
>     Hartwig> That's it - I tryed to switch-off some before, but forgot
>     Hartwig> to disable bsdcomp and ccp. The CCP is the bad thing!
> 
> Does `-bsdcomp' alone already fix the problem?
no, it still kills the interup-handler!!!

> Does the problem only occur with demand dial-up or even if you start
> the connection manually (isdnctrl dial ippp0)?
In my testprocedure, I only used "isdnctrl dial" followed by a sync
command, and "less /var/log/messages" and F, to see some debug-messages,
that are near the bad operation.

> Ss you can reproduce the problem with a Linux 2.2.x peer server
> in your office (which does not crash), it should also be possible to 
> additinally capture the (syslog-based) log at the server side.
- --------------o<-------------
Oct 19 00:13:37 fog ipppd[186]: sent [0][CCP ConfReq id=0x2]
Oct 19 00:13:58 fog last message repeated 7 times
Oct 19 00:14:01 fog ipppd[186]: CCP: timeout sending Config-Requests
Oct 19 00:15:22 fog kernel: ippp0: remote hangup
- ------------>o---------
I think, this is the reason, logged from the remote (the non-crashing
server). The whole negotiation is done, besides CCP - IP is up. As I
fetched this file, I used on both sides Linux-2.2 with CCP/LZS
compression, as the logs stated.

When I got a little time to spare, I will dig further!

ReadU hartwig
P.S.: If somebody needs the whole parts of the messages file (2 tryes, 1.
the crashed one part, and 2. the working Linux-2.2 vs Linux-2.2)

- -- 
1024D/339FD693 Hartwig Felger <hgfelger@hgfelger.de>
Key fingerprint = FB2F 3EE9 345A D55B 6FF2  0EC1 F5B0 684F 339F D693
For the pulic keys, please visit my page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE57i819bBoTzOf1pMRApnlAKDZSjHQsescNWYSFml0n8R0a9xrUQCgnhZw
4Wn/6GosSG4tLTBRtZDKWMQ=
=cmGr
-----END PGP SIGNATURE-----


From owner-netdev@oss.sgi.com Thu Oct 19 00:13:49 2000
Received:  by oss.sgi.com id <S553663AbQJSHNj>;
	Thu, 19 Oct 2000 00:13:39 -0700
Received: from asbestos.linuxcare.com.au ([203.17.0.30]:4337 "HELO
        halfway.linuxcare.com.au") by oss.sgi.com with SMTP
	id <S553656AbQJSHNZ>; Thu, 19 Oct 2000 00:13:25 -0700
Received: from linuxcare.com.au (localhost [127.0.0.1])
	by halfway.linuxcare.com.au (Postfix) with ESMTP
	id 34E4581E6; Thu, 19 Oct 2000 18:13:17 +1100 (EST)
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     netdev@oss.sgi.com
Cc:     davem@redhat.com
Subject: [PATCH] 2.4.0-test10-pre4 shutdown() hack to wake listeners.
Date:   Thu, 19 Oct 2000 18:13:16 +1100
Message-Id: <20001019071318.34E4581E6@halfway.linuxcare.com.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Some people (one of whom is a client) expects all threads to wake up
when the master closes the UDP socket they are listening on (as per
Solaris).  Working around this in userspace proves to be a complete
PITA.

shutdown(fd) does the job on connected sockets, but POSIX specifies
that it must return ENOTCONN if it's not connected.  This patch makes
it tickle POLLHUP anyway.  Normally doesn't matter, but this way you
can emulate other platforms' threads behavior by doing:

	int my_close(int fd)
	{
		struct stat st;
		if (fstat(fd, &st) == 0 && S_ISSOCK(st.st_mode))
			shutdown(fd, 2);
		return close(fd);
	}

Thoughts?
Rusty.

diff -urN -X /tmp/kerndiff.IDDSS7 --minimal linux-2.4.0-test10-4/net/ipv4/af_inet.c working-2.4.0-test10-4/net/ipv4/af_inet.c
--- linux-2.4.0-test10-4/net/ipv4/af_inet.c	Thu Oct 19 14:08:34 2000
+++ working-2.4.0-test10-4/net/ipv4/af_inet.c	Thu Oct 19 18:03:23 2000
@@ -753,13 +753,14 @@
 	}
 
 	switch (sk->state) {
-	default:	
+	case TCP_CLOSE:
+		err = -ENOTCONN;
+		/* Hack to wake up other listeners, who can poll for
+		   POLLHUP, even on eg. unconnected UDP sockets -- RR */
+	default:
 		sk->shutdown |= how;
 		if (sk->prot->shutdown)
 			sk->prot->shutdown(sk, how);
-		break;
-	case TCP_CLOSE:
-		err = -ENOTCONN;
 		break;
 
 	/* Remaining two branches are temporary solution for missing
--
Hacking time.

From owner-netdev@oss.sgi.com Thu Oct 19 08:31:14 2000
Received:  by oss.sgi.com id <S553686AbQJSPbE>;
	Thu, 19 Oct 2000 08:31:04 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:54534 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553677AbQJSPat>;
	Thu, 19 Oct 2000 08:30:49 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA24428; Thu, 19 Oct 2000 19:30:21 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010191530.TAA24428@ms2.inr.ac.ru>
Subject: Re: [PATCH] 2.4.0-test10-pre4 shutdown() hack to wake listeners.
To:     rusty@linuxcare.COM.AU (Rusty Russell)
Date:   Thu, 19 Oct 2000 19:30:21 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20001019071318.34E4581E6@halfway.linuxcare.com.au> from "Rusty Russell" at Oct 19, 0 11:45:00 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 41        
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Thoughts?

Right idea.

Alexey

From owner-netdev@oss.sgi.com Thu Oct 19 09:20:14 2000
Received:  by oss.sgi.com id <S553681AbQJSQUE>;
	Thu, 19 Oct 2000 09:20:04 -0700
Received: from 24.69.164.40.on.wave.home.com ([24.69.164.40]:20462 "EHLO
        odysseus.cybertor.com") by oss.sgi.com with ESMTP
	id <S553656AbQJSQTo>; Thu, 19 Oct 2000 09:19:44 -0700
Received: from cybertor.com (ntorys@localhost [127.0.0.1])
	by odysseus.cybertor.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id MAA01264
	for <netdev@oss.sgi.com>; Thu, 19 Oct 2000 12:19:34 -0400
From:   ntorys@cybertor.com
Message-Id: <200010191619.MAA01264@odysseus.cybertor.com>
X-Authentication-Warning: odysseus.cybertor.com: Host ntorys@localhost [127.0.0.1] claimed to be cybertor.com
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To:     netdev@oss.sgi.com
Subject: mirror problems. 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 19 Oct 2000 12:19:34 -0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Hi there,

I would like to correct my previous note regarding mirror problems. I am not 
sure that it's
2.4.0's problem after all. Today I was mirroring Debian using 2.2.17 and I had 
the same
problems.
I tried again after I slowed the CPU and the memory memory, and everything 
went fine.
So maybe it's me pushing the mother board too much, by overclocking it.
Sorry for me bothering you.

Regards,


-- 
Nick Torys      - Cybertor Enterprises Ltd. 
                - Markham, Ont, Canada
                - Phone (905) 471-0600
                - ntorys@cybertor.com
                - Instrumentation for Process Control Industry
                                                                




From owner-netdev@oss.sgi.com Thu Oct 19 10:07:06 2000
Received:  by oss.sgi.com id <S553700AbQJSRGp>;
	Thu, 19 Oct 2000 10:06:45 -0700
Received: from pizda.ninka.net ([216.101.162.242]:8320 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S553690AbQJSRGe>;
	Thu, 19 Oct 2000 10:06:34 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id JAA00886;
	Thu, 19 Oct 2000 09:52:45 -0700
Date:   Thu, 19 Oct 2000 09:52:45 -0700
Message-Id: <200010191652.JAA00886@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     rusty@linuxcare.com.au
CC:     netdev@oss.sgi.com
In-reply-to: <20001019071318.34E4581E6@halfway.linuxcare.com.au> (message from
	Rusty Russell on Thu, 19 Oct 2000 18:13:16 +1100)
Subject: Re: [PATCH] 2.4.0-test10-pre4 shutdown() hack to wake listeners.
References:  <20001019071318.34E4581E6@halfway.linuxcare.com.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   From: Rusty Russell <rusty@linuxcare.com.au>
   Date: Thu, 19 Oct 2000 18:13:16 +1100

   Thoughts?

I agree with Alexey, this seems fine and harmless.

Patch applied, thanks.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Thu Oct 19 12:19:06 2000
Received:  by oss.sgi.com id <S553720AbQJSTS4>;
	Thu, 19 Oct 2000 12:18:56 -0700
Received: from ikar.t17.ds.pwr.wroc.pl ([156.17.210.253]:1041 "HELO
        ikar.t17.ds.pwr.wroc.pl") by oss.sgi.com with SMTP
	id <S553677AbQJSTSj>; Thu, 19 Oct 2000 12:18:39 -0700
Received: by ikar.t17.ds.pwr.wroc.pl (Postfix+IPv6, from userid 1002)
	id 43E27C8059; Thu, 19 Oct 2000 19:16:55 +0200 (CEST)
Date:   Thu, 19 Oct 2000 19:16:55 +0200
From:   Arkadiusz Miskiewicz <misiek@pld.org.pl>
To:     netdev@oss.sgi.com
Subject: sin_zero (again)
Message-ID: <20001019191655.A29261@ikar.t17.ds.pwr.wroc.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
X-URL:  http://www.misiek.eu.org/ipv6/
X-Operating-System: Linux sunsite 4.0.20 #119 Tue Jan 16 12:21:53 MET 2001 i986 pld
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


In May 2000 I was asking here about sin_zero problem. getpeername for example
writes some random data to sin_zero while IMHO it should leave sin_zero alone.

24          memset(&ss, 0, sizeof(ss));
(gdb)
25          getpeername(s, (struct sockaddr *)&ss, &sslen);
(gdb) print *(struct sockaddr_in *)&ss
$1 = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0},
  sin_zero = "\000\000\000\000\000\000\000"}
(gdb) n
26          printf("eot\n");
(gdb) print *(struct sockaddr_in *)&ss
$2 = {sin_family = 2, sin_port = 6400, sin_addr = {s_addr = 16777343}, sin_zero = "i\212\020ŔPĄşŔ"}
(gdb)

Someone posted small fix, but it wasn't applied to kernel src.
What's the reason ?

-- 
Arkadiusz Mi¶kiewicz         http://www.misiek.eu.org/ipv6/
PLD GNU/Linux [IPv6 enabled]    http://www.pld.org.pl/

From owner-netdev@oss.sgi.com Thu Oct 19 14:55:07 2000
Received:  by oss.sgi.com id <S553739AbQJSVy5>;
	Thu, 19 Oct 2000 14:54:57 -0700
Received: from kogge.hanse.de ([192.76.134.17]:29707 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553734AbQJSVyt>;
	Thu, 19 Oct 2000 14:54:49 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id XAA85475;
	Thu, 19 Oct 2000 23:55:20 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id VAA02042;
	Thu, 19 Oct 2000 21:21:06 +0200
Date:   Thu, 19 Oct 2000 21:21:06 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200010191921.VAA02042@baty.hanse.de>
To:     hgfelger@hgfelger.de
CC:     netdev@oss.sgi.com, i4ldeveloper@listserv.isdn4linux.de
In-reply-to: <Pine.LNX.4.10.10010190028170.364-100000@frog.athome> (message
	from Hartwig Felger on Thu, 19 Oct 2000 01:16:00 +0200 (CEST))
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
References:  <Pine.LNX.4.10.10010190028170.364-100000@frog.athome>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "Hartwig" == Hartwig Felger <hgfelger@hgfelger.de> writes:

    Hartwig> ipppd[186]: sent [0][CCP ConfReq id=0x2]
    Hartwig> last message repeated 7 times
    Hartwig> ipppd[186]: CCP: timeout sending Config-Requests Oct 19

Fine, this already narrows down the code region in question pretty much.

    Hartwig> fetched this file, I used on both sides Linux-2.2 with
    Hartwig> CCP/LZS compression, as the logs stated.

Ah, LZS compression!

Does the crash also occur if you enable CCP, but disable only
lzs compression (`-lzs' option)?

 Please bear in mind:
1) LZS (=Stac) compression is alpha
2) LZS is not shipped with the standard kernel due to patent problems
   in certain countries.

(2) implies that you need to compile the isdn_lzscomp.c sources
from the isdn4k_utils yourself (against the proper kernel header files)
and to insmod it before the ppp session.

Have you done so?
Does `lsmod' before starting ppp indicate that isdn_lzscomp is loaded?
Is there an isdn_lzscomp.o below /lib/modules/2.4.0-test9/?
Could it be that an old version of isdn_lzscomp is loaded into the new
kernel without insmod warning about this? 

Except for the last scenario, the kernel should never crash. Everything
else would be a bug in the isdn code.

    Hartwig> When I got a little time to spare, I will dig further!

    Hartwig> P.S.: If somebody needs the whole parts of
    Hartwig> the messages file (2 tryes, 1.  the crashed one part, and
    Hartwig> 2. the working Linux-2.2 vs Linux-2.2)

I guess that's not that important right now. The last CCP konsole messages
resulting from ipppd's kdebug option are probably more informative. But
first, the answers to the questions above and a test with `-lzs' should
be even more important.

Henner

From owner-netdev@oss.sgi.com Fri Oct 20 04:44:42 2000
Received:  by oss.sgi.com id <S553673AbQJTLob>;
	Fri, 20 Oct 2000 04:44:31 -0700
Received: from 24.69.164.40.on.wave.home.com ([24.69.164.40]:54001 "EHLO
        odysseus.cybertor.com") by oss.sgi.com with ESMTP
	id <S553660AbQJTLoK>; Fri, 20 Oct 2000 04:44:10 -0700
Received: from cybertor.com (ntorys@localhost [127.0.0.1])
	by odysseus.cybertor.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id HAA00683
	for <netdev@oss.sgi.com>; Fri, 20 Oct 2000 07:44:03 -0400
From:   ntorys@cybertor.com
Message-Id: <200010201144.HAA00683@odysseus.cybertor.com>
X-Authentication-Warning: odysseus.cybertor.com: Host ntorys@localhost [127.0.0.1] claimed to be cybertor.com
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To:     netdev@oss.sgi.com
Subject: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Fri, 20 Oct 2000 07:44:03 -0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi (it's me again),

O.K. I tried the mirror this morning (at normal CPU) speed) and
the 2.4.0-test9 died after about ten files. I re-tried mirror
using 2.2.17 and the mirror worked fine to the finish.

I will not bother you again, not for a while anyway.
Thanks for the great OS, guys.

Regards,

Nick


From owner-netdev@oss.sgi.com Fri Oct 20 09:23:14 2000
Received:  by oss.sgi.com id <S553682AbQJTQXE>;
	Fri, 20 Oct 2000 09:23:04 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:9231 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553663AbQJTQWq>;
	Fri, 20 Oct 2000 09:22:46 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA07705; Fri, 20 Oct 2000 20:22:29 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010201622.UAA07705@ms2.inr.ac.ru>
Subject: Re: sin_zero (again)
To:     misiek@pld.ORG.PL (Arkadiusz Miskiewicz)
Date:   Fri, 20 Oct 2000 20:22:29 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20001019191655.A29261@ikar.t17.ds.pwr.wroc.pl> from "Arkadiusz Miskiewicz" at Oct 19, 0 11:45:00 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 457       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Someone posted small fix, but it wasn't applied to kernel src.
> What's the reason ?

No reasons, I think. Actually, I thought this patch has been applied.

Exactly opposite statement is even more true: this feature is so old, that
it has absolutely no sense to repair this. In fact, the bug is that
this useless padding exists. 8) I do not think that guy who invented
this shit is still alive. Happy programmers killed him, no doubts. 8)

Alexey

From owner-netdev@oss.sgi.com Fri Oct 20 10:07:35 2000
Received:  by oss.sgi.com id <S553722AbQJTRHY>;
	Fri, 20 Oct 2000 10:07:24 -0700
Received: from natmail2.webmailer.de ([192.67.198.65]:34705 "EHLO
        post.webmailer.de") by oss.sgi.com with ESMTP id <S553679AbQJTRHK>;
	Fri, 20 Oct 2000 10:07:10 -0700
Received: from frog.athome (pec-117-224.tnt8.s2.uunet.de [149.225.117.224])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id TAA29716;
	Fri, 20 Oct 2000 19:07:06 +0200 (MET DST)
From:   liste@hgfelger.de
Received: from localhost (hgfelger@localhost)
	by frog.athome (8.9.3/8.9.3) with ESMTP id TAA01449;
	Fri, 20 Oct 2000 19:07:12 +0200
X-Authentication-Warning: frog.athome: hgfelger owned process doing -bs
Date:   Fri, 20 Oct 2000 19:07:05 +0200 (CEST)
X-Sender: hgfelger@frog.athome
Reply-To: hgfelger@hgfelger.de
To:     Henner Eisen <eis@baty.hanse.de>
cc:     netdev@oss.sgi.com, i4ldeveloper@listserv.isdn4linux.de
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
In-Reply-To: <200010191921.VAA02042@baty.hanse.de>
Message-ID: <Pine.LNX.4.10.10010201554200.1413-200000@frog.athome>
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="-1463811592-290172460-972061625=:1413"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---1463811592-290172460-972061625=:1413
Content-Type: text/plain; charset=us-ascii

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salut Henner,
On Thu, 19 Oct 2000, Henner Eisen wrote:
>     Hartwig> ipppd[186]: sent [0][CCP ConfReq id=0x2]
>     Hartwig> last message repeated 7 times
>     Hartwig> ipppd[186]: CCP: timeout sending Config-Requests Oct 19
> Fine, this already narrows down the code region in question pretty much.
>     Hartwig> fetched this file, I used on both sides Linux-2.2 with
>     Hartwig> CCP/LZS compression, as the logs stated.
> Ah, LZS compression!
> 
> Does the crash also occur if you enable CCP, but disable only
> lzs compression (`-lzs' option)?
no, that does not solve it - it still crashes. In my linux2.4-tree, there
is only one file-name containing lzs -> include/linux/isdn_lzscomp.h, but
no .c-file. There does not exist a module.
But the other side (the office-linux-box) includes this module.
The ISP Planet-intercom also provides LZS.

 > 
>  Please bear in mind:
> 1) LZS (=Stac) compression is alpha
> 2) LZS is not shipped with the standard kernel due to patent problems
>    in certain countries.
Yes, I do not need it. But I think linux should not crash...
> 
> (2) implies that you need to compile the isdn_lzscomp.c sources
> from the isdn4k_utils yourself (against the proper kernel header files)
> and to insmod it before the ppp session.
n.A.
> Does `lsmod' before starting ppp indicate that isdn_lzscomp is loaded?
> Is there an isdn_lzscomp.o below /lib/modules/2.4.0-test9/?
> Could it be that an old version of isdn_lzscomp is loaded into the new
> kernel without insmod warning about this? 
no!
> Except for the last scenario, the kernel should never crash. Everything
> else would be a bug in the isdn code.

> I guess that's not that important right now. The last CCP konsole messages
> resulting from ipppd's kdebug option are probably more informative. But
I attached, what I could capture via ssh and tail -f /var/log/message,
after previously starting ipppd with kdebug 0xff. But I think, it's time
to look into the sources (as soon, as I can spare a little time). As my
motorcycle has a fuel-leak, it is really dangerous (when it drops onto the
rear wheel). So this needs to be fixed first.

- -- 
1024D/339FD693 Hartwig Felger <hgfelger@hgfelger.de>
Key fingerprint = FB2F 3EE9 345A D55B 6FF2  0EC1 F5B0 684F 339F D693
For the pulic keys, please visit my page.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE58HvA9bBoTzOf1pMRAh96AKDW+XmcnDcOyNuyKM55WPHpoSzpVgCg3pys
nSLusHMEHhScB2Tj+b15mQw=
=1YMv
-----END PGP SIGNATURE-----

---1463811592-290172460-972061625=:1413
Content-Type: text/plain; charset=us-ascii; name="ccp.txt"
Content-Transfer-Encoding: base64
Content-ID: <Pine.LNX.4.10.10010201907050.1413@frog.athome>
Content-Description: 
Content-Disposition: attachment; filename="ccp.txt"

T2N0IDIwIDE2OjE4OjMyIGRvZyBpcHBwZFszMzVdOiBMb2NhbCBudW1iZXI6
IDIxLCBSZW1vdGUgbnVtYmVyOiAwOTc1NjE5NTIsIFR5cGU6IG91dGdvaW5n
DQpPY3QgMjAgMTY6MTg6MzIgZG9nIGlwcHBkWzMzNV06IFBIQVNFX1dBSVQg
LT4gUEhBU0VfRVNUQUJMSVNIRUQsIGlmdW5pdDogNywgbGlua3VuaXQ6IDAs
IGZkOiA3DQpPY3QgMjAgMTY6MTg6MzIgZG9nIGlwcHBkWzMzNV06IHNlbnQg
WzBdW0xDUCBDb25mUmVxIGlkPTB4MSA8bXJ1IDE1MDA+IDxtYWdpYyAweDMy
Y2NkODcwPiA8cGNvbXA+IDxhY2NvbXA+XQ0KT2N0IDIwIDE2OjE4OjMyIGRv
ZyBrZXJuZWw6IHBwcCB4bWl0OiBsZW4gMjINCk9jdCAyMCAxNjoxODozMiBk
b2cga2VybmVsOiBbNy8wXS54bWl0WzBdOiBmZiAwMyBjMCAyMSAwMSAwMSAw
MCAxMiAwMSAwNCAwNSBkYyAwNSAwNiAzMiBjYw0KT2N0IDIwIDE2OjE4OjMy
IGRvZyBrZXJuZWw6IFs3LzBdLnhtaXRbMV06IGQ4IDcwIDA3IDAyIDA4IDAy
DQpPY3QgMjAgMTY6MTg6MzIgZG9nIGtlcm5lbDogaXNkbl9wcHBfcG9sbDog
bWlub3I6IDEzNQ0KT2N0IDIwIDE2OjE4OjMyIGRvZyBrZXJuZWw6IGlwcHBf
cmVjZWl2ZTogaXM6YzFjNzYwMDAgbHA6YzEzYWMyMDAgc2xvdDowIHVuaXQ6
Nw0KbGVuOjIyDQpPY3QgMjAgMTY6MTg6MzIgZG9nIGtlcm5lbDogWzcvMF0u
cmVjZWl2ZVswXTogZmYgMDMgYzAgMjEgMDIgMDEgMDAgMTIgMDEgMDQgMDUg
ZGMgMDUgMDYgMzIgY2MNCk9jdCAyMCAxNjoxODozMiBkb2cga2VybmVsOiBb
Ny8wXS5yZWNlaXZlWzFdOiBkOCA3MCAwNyAwMiAwOCAwMg0KT2N0IDIwIDE2
OjE4OjMyIGRvZyBrZXJuZWw6IHB1c2gsIHNrYiAxOCBjMDIxDQpPY3QgMjAg
MTY6MTg6MzIgZG9nIGtlcm5lbDogWzcvMF0ucnB1c2hbMF06IDAyIDAxIDAw
IDEyIDAxIDA0IDA1IGRjIDA1IDA2IDMyIGNjDQpkOCA3MCAwNyAwMg0KT2N0
IDIwIDE2OjE4OjMyIGRvZyBrZXJuZWw6IFs3LzBdLnJwdXNoWzFdOiAwOCAw
Mg0KT2N0IDIwIDE2OjE4OjMyIGRvZyBrZXJuZWw6IGlzZG5fcHBwX3BvbGw6
IG1pbm9yOiAxMzUNCk9jdCAyMCAxNjoxODozMiBkb2cgaXBwcGRbMzM1XTog
cmN2ZCBbMF1bTENQIENvbmZBY2sgaWQ9MHgxIDxtcnUgMTUwMD4gPG1hZ2lj
IDB4MzJjY2Q4NzA+IDxwY29tcD4gPGFjY29tcD5dDQpPY3QgMjAgMTY6MTg6
MzIgZG9nIGtlcm5lbDogaXNkbl9wcHBfcG9sbDogbWlub3I6IDEzNQ0KDQo=
---1463811592-290172460-972061625=:1413--

From owner-netdev@oss.sgi.com Fri Oct 20 12:48:35 2000
Received:  by oss.sgi.com id <S553720AbQJTTs0>;
	Fri, 20 Oct 2000 12:48:26 -0700
Received: from ikar.t17.ds.pwr.wroc.pl ([156.17.210.253]:9993 "HELO
        ikar.t17.ds.pwr.wroc.pl") by oss.sgi.com with SMTP
	id <S553728AbQJTTsO>; Fri, 20 Oct 2000 12:48:14 -0700
Received: by ikar.t17.ds.pwr.wroc.pl (Postfix+IPv6, from userid 1002)
	id 066BDC805A; Fri, 20 Oct 2000 19:46:22 +0200 (CEST)
Date:   Fri, 20 Oct 2000 19:46:22 +0200
From:   Arkadiusz Miskiewicz <misiek@pld.ORG.PL>
To:     kuznet@ms2.inr.ac.ru
Cc:     netdev@oss.sgi.com
Subject: Re: sin_zero (again)
Message-ID: <20001020194622.A2958@pld.org.pl>
References: <20001019191655.A29261@ikar.t17.ds.pwr.wroc.pl> <200010201622.UAA07705@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <200010201622.UAA07705@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Fri, Oct 20, 2000 at 08:22:29PM +0400
X-URL:  http://www.misiek.eu.org/ipv6/
X-Operating-System: Linux dark 4.0.20 #119 Tue Jan 16 12:21:53 MET 2001 i986 pld
X-Team: Polish Linux Distribution Team Member
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Oct 20, 2000 at 08:22:29PM +0400, kuznet@ms2.inr.ac.ru wrote / Dnia Fri, Oct 20, 2000 at 08:22:29PM +0400, kuznet@ms2.inr.ac.ru napisał(a):
> Hello!
> 
> Exactly opposite statement is even more true: this feature is so old, that
> it has absolutely no sense to repair this. 
It's easy to repair so why don't fix it ?

> In fact, the bug is that this useless padding exists. 8) I do not think
> that guy who invented this shit is still alive. Happy programmers killed
> him, no doubts. 8)
:-)

> Alexey

-- 
Arkadiusz Mi¶kiewicz         http://www.misiek.eu.org/ipv6/
PLD GNU/Linux [IPv6 enabled]    http://www.pld.org.pl/

From owner-netdev@oss.sgi.com Fri Oct 20 14:14:06 2000
Received:  by oss.sgi.com id <S553663AbQJTVN5>;
	Fri, 20 Oct 2000 14:13:57 -0700
Received: from natmail2.webmailer.de ([192.67.198.65]:25014 "EHLO
        post.webmailer.de") by oss.sgi.com with ESMTP id <S553655AbQJTVNg>;
	Fri, 20 Oct 2000 14:13:36 -0700
Received: from frog.athome (pec-115-101.tnt7.s2.uunet.de [149.225.115.101])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id XAA21059;
	Fri, 20 Oct 2000 23:13:33 +0200 (MET DST)
From:   liste@hgfelger.de
Received: from localhost (hgfelger@localhost)
	by frog.athome (8.9.3/8.9.3) with ESMTP id XAA02072;
	Fri, 20 Oct 2000 23:13:37 +0200
X-Authentication-Warning: frog.athome: hgfelger owned process doing -bs
Date:   Fri, 20 Oct 2000 23:13:31 +0200 (CEST)
X-Sender: hgfelger@frog.athome
Reply-To: hgfelger@hgfelger.de
To:     Henner Eisen <eis@baty.hanse.de>
cc:     netdev@oss.sgi.com, i4ldeveloper@listserv.isdn4linux.de
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
In-Reply-To: <200010191921.VAA02042@baty.hanse.de>
Message-ID: <Pine.LNX.4.10.10010202256400.2056-200000@frog.athome>
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="-1463811592-369356796-972076411=:2056"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---1463811592-369356796-972076411=:2056
Content-Type: text/plain; charset=us-ascii

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I now test with test10pre4
Salut Henner,
I had a quick look into the source. As it always crashed in kfree_skb, 
I changed some lines in net/core/skbuff.c (see attached patch). But this
is not a cure - it only does not crash, at least not immediatly.
The section, I changed should report a bug - this reporting did crash the
machine. But it would be a cure, if we could fix this bug, that wants to
get reported
  Warning: kfree_skb passed an skb still on a list (from
<isdn_ppp_push_higher+0x298>).

Maybe, someone knows a bit more, what this message wants to tell us?

I tryed to connect with -lzs option, and a second time with noccp -lzs.
The second try did not report the warning, as expected. A ping to the peer
did bothtimes succeed.

Regards hartwig :-)

- -- 
1024D/339FD693 Hartwig Felger <hgfelger@hgfelger.de>
Key fingerprint = FB2F 3EE9 345A D55B 6FF2  0EC1 F5B0 684F 339F D693
For the pulic keys, please visit my page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE58LWB9bBoTzOf1pMRAp1dAJ95td51p4SKzy33GgzbQn8C8jLLZgCgmIu9
Z8oVr92h6xHXh4XXa243cB4=
=yLfc
-----END PGP SIGNATURE-----

---1463811592-369356796-972076411=:2056
Content-Type: text/plain; charset=us-ascii; name="skbuff.c.diff"
Content-Transfer-Encoding: base64
Content-ID: <Pine.LNX.4.10.10010202313310.2056@frog.athome>
Content-Description: 
Content-Disposition: attachment; filename="skbuff.c.diff"

LS0tIHNrYnVmZi5jLm9yaQlGcmkgT2N0IDIwIDE5OjUzOjUyIDIwMDANCisr
KyBza2J1ZmYuYwlGcmkgT2N0IDIwIDIzOjAwOjQxIDIwMDANCkBAIC0yNzEs
OSArMjcxLDExIEBADQogdm9pZCBfX2tmcmVlX3NrYihzdHJ1Y3Qgc2tfYnVm
ZiAqc2tiKQ0KIHsNCiAJaWYgKHNrYi0+bGlzdCkgew0KKwkgCXByaW50ayhL
RVJOX1dBUk5JTkcgImlncyBrZnJlZV9za2IgcGFzc2VkIGFuIHNrYiBzdGls
bCAiKTsNCiAJIAlwcmludGsoS0VSTl9XQVJOSU5HICJXYXJuaW5nOiBrZnJl
ZV9za2IgcGFzc2VkIGFuIHNrYiBzdGlsbCAiDQogCQkgICAgICAgIm9uIGEg
bGlzdCAoZnJvbSAlcCkuXG4iLCBORVRfQ0FMTEVSKHNrYikpOw0KLQkJQlVH
KCk7DQorCQkvLwkJQlVHKCk7DQorcmV0dXJuOw0KIAl9DQogDQogCWRzdF9y
ZWxlYXNlKHNrYi0+ZHN0KTsNCg==
---1463811592-369356796-972076411=:2056--

From owner-netdev@oss.sgi.com Sun Oct 22 06:29:18 2000
Received:  by oss.sgi.com id <S553770AbQJVN3I>;
	Sun, 22 Oct 2000 06:29:08 -0700
Received: from pop3.galileo.co.il ([199.203.130.130]:9622 "EHLO
        galileo5.galileo.co.il") by oss.sgi.com with ESMTP
	id <S553767AbQJVN2t>; Sun, 22 Oct 2000 06:28:49 -0700
Received: from galileo.co.il (rabeeh@linux2.galileo.co.il [10.2.40.2])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id PAA15066
	for <netdev@oss.sgi.com>; Sun, 22 Oct 2000 15:28:31 +0200 (GMT-2)
Message-ID: <39F2EB02.39029517@galileo.co.il>
Date:   Sun, 22 Oct 2000 15:26:26 +0200
From:   Rabeeh Khoury <rabeeh@galileo.co.il>
Reply-To: rabeeh@galileo.co.il
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev <netdev@oss.sgi.com>
Subject: FrameRelay packets
Content-Type: multipart/mixed;
 boundary="------------69394B1D5701F53F010554FF"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This is a multi-part message in MIME format.
--------------69394B1D5701F53F010554FF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi All,

I am developing FrameRelay interfaces over our (Galileo Technology)
embedded systems; when getting the FrameRelay packet from higher levels
(dlci devices) the packet is not 64-bit alligned. I need this alignment
in order to achieve maximum throughput.

The ethernet packets that I receive from upper layers are always 64-bit
aligned, I tried to find what is the difference between dlci devices (10
bytes header) and ethernet devices (14 bytes header) in their netdev
declarations that makes ethernet devices to be aligned, but I didn't
find any thing special. Does any one know how to fix this ? (low cost
fix without using any skb_* functions to copy the packet then aligning
it !)


Regards,
Rabeeh

--------------69394B1D5701F53F010554FF
Content-Type: text/x-vcard; charset=us-ascii;
 name="rabeeh.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Rabeeh Khoury
Content-Disposition: attachment;
 filename="rabeeh.vcf"

begin:vcard 
n:Khoury;Rabeeh
x-mozilla-html:FALSE
org:Galileo Technology;Software Department
adr:;;;;;;
version:2.1
email;internet:rabeeh@galileo.co.il
title:Development Engineer
x-mozilla-cpt:;-31712
fn:Rabeeh Khoury
end:vcard

--------------69394B1D5701F53F010554FF--


From owner-netdev@oss.sgi.com Sun Oct 22 09:12:09 2000
Received:  by oss.sgi.com id <S553771AbQJVQL7>;
	Sun, 22 Oct 2000 09:11:59 -0700
Received: from kogge.hanse.de ([192.76.134.17]:56593 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553717AbQJVQLm>;
	Sun, 22 Oct 2000 09:11:42 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id SAA85846;
	Sun, 22 Oct 2000 18:13:29 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id AAA21014;
	Sun, 22 Oct 2000 00:31:16 +0200
Date:   Sun, 22 Oct 2000 00:31:16 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200010212231.AAA21014@baty.hanse.de>
To:     hgfelger@hgfelger.de
CC:     netdev@oss.sgi.com, i4ldeveloper@listserv.isdn4linux.de
In-reply-to: <Pine.LNX.4.10.10010201554200.1413-200000@frog.athome>
	(liste@hgfelger.de)
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
References:  <Pine.LNX.4.10.10010201554200.1413-200000@frog.athome>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "liste" == liste  <liste@hgfelger.de> writes:
    >> 
    >> Does the crash also occur if you enable CCP, but disable only
    >> lzs compression (`-lzs' option)?
    liste> no, that does not solve it - it still crashes. In my
    liste> linux2.4-tree, there is only one file-name containing lzs
    liste> -> include/linux/isdn_lzscomp.h, but no .c-file. There does
    liste> not exist a module.  But the other side (the
    liste> office-linux-box) includes this module.  The ISP
    liste> Planet-intercom also provides LZS.

Important observation! It indicates that the problem is not LZS-specific
but more directly related to CCP itsself.

Henner
 

From owner-netdev@oss.sgi.com Sun Oct 22 09:12:28 2000
Received:  by oss.sgi.com id <S553773AbQJVQMJ>;
	Sun, 22 Oct 2000 09:12:09 -0700
Received: from kogge.hanse.de ([192.76.134.17]:57361 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553768AbQJVQLt>;
	Sun, 22 Oct 2000 09:11:49 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id SAA85856;
	Sun, 22 Oct 2000 18:13:42 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id BAA21084;
	Sun, 22 Oct 2000 01:16:14 +0200
Date:   Sun, 22 Oct 2000 01:16:14 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200010212316.BAA21084@baty.hanse.de>
To:     hgfelger@hgfelger.de
CC:     netdev@oss.sgi.com, i4ldeveloper@listserv.isdn4linux.de
In-reply-to: <Pine.LNX.4.10.10010202256400.2056-200000@frog.athome>
	(liste@hgfelger.de)
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
References:  <Pine.LNX.4.10.10010202256400.2056-200000@frog.athome>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "liste" == liste  <liste@hgfelger.de> writes:

    liste> reported Warning: kfree_skb passed an skb still on a list
    liste> (from <isdn_ppp_push_higher+0x298>).

    liste> Maybe, someone knows a bit more, what this message wants to
    liste> tell us?

In principal it means that the skb is still queued somewhere when caller
tries to free it. In practice, it frequently indicates that a dangling
skb pointer or a pointer not related to an skb was passed to
kfree_skb(). That's probably what's happening here. The kernel
crash symptoms you describe are also typical for such class of bug.

It also indicates that the bug is probably not inside isdn_ppp, but
somewhere else (in the lower isdn layers, or even somewhere totally
unrelated).

BTW, is your kernel SMP?

Henner


From owner-netdev@oss.sgi.com Sun Oct 22 10:28:30 2000
Received:  by oss.sgi.com id <S553785AbQJVR2K>;
	Sun, 22 Oct 2000 10:28:10 -0700
Received: from xerxes.thphy.uni-duesseldorf.de ([134.99.64.10]:10477 "EHLO
        xerxes.thphy.uni-duesseldorf.de") by oss.sgi.com with ESMTP
	id <S553781AbQJVR1i>; Sun, 22 Oct 2000 10:27:38 -0700
Received: from chaos.thphy.uni-duesseldorf.de (IDENT:root@chaos [134.99.64.99])
	by xerxes.thphy.uni-duesseldorf.de (8.9.3/8.9.3) with ESMTP id TAA20468;
	Sun, 22 Oct 2000 19:27:01 +0200 (MET DST)
Received: from localhost (kai@localhost)
	by chaos.thphy.uni-duesseldorf.de (8.9.3/8.8.7) with ESMTP id TAA09389;
	Sun, 22 Oct 2000 19:27:35 +0200
X-Authentication-Warning: chaos.thphy.uni-duesseldorf.de: kai owned process doing -bs
Date:   Sun, 22 Oct 2000 19:27:35 +0200 (CEST)
From:   Kai Germaschewski <kai@thphy.uni-duesseldorf.de>
To:     Henner Eisen <eis@baty.hanse.de>
cc:     hgfelger@hgfelger.de, netdev@oss.sgi.com,
        i4ldeveloper@listserv.isdn4linux.de
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
In-Reply-To: <200010212316.BAA21084@baty.hanse.de>
Message-ID: <Pine.LNX.4.10.10010221926030.9383-100000@chaos.thphy.uni-duesseldorf.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi!

On Sun, 22 Oct 2000, Henner Eisen wrote:

> >>>>> "liste" == liste  <liste@hgfelger.de> writes:
> 
>     liste> reported Warning: kfree_skb passed an skb still on a list
>     liste> (from <isdn_ppp_push_higher+0x298>).

> In principal it means that the skb is still queued somewhere when caller
> tries to free it. In practice, it frequently indicates that a dangling
> skb pointer or a pointer not related to an skb was passed to
> kfree_skb(). That's probably what's happening here. The kernel
> crash symptoms you describe are also typical for such class of bug.
> 
> It also indicates that the bug is probably not inside isdn_ppp, but
> somewhere else (in the lower isdn layers, or even somewhere totally
> unrelated).

Actually, I think the problem is in isdn_ppp.c, I guess we're caught by
the slab poisoning in 2.4 when looking at an already freed skb. I'll try
to look into it tonight.

--Kai



From owner-netdev@oss.sgi.com Sun Oct 22 15:23:13 2000
Received:  by oss.sgi.com id <S553663AbQJVWXC>;
	Sun, 22 Oct 2000 15:23:02 -0700
Received: from natmail2.webmailer.de ([192.67.198.65]:13985 "EHLO
        post.webmailer.de") by oss.sgi.com with ESMTP id <S553655AbQJVWWp>;
	Sun, 22 Oct 2000 15:22:45 -0700
Received: from frog.athome (pec-44-216.tnt3.s2.uunet.de [149.225.44.216])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id AAA16658;
	Mon, 23 Oct 2000 00:22:42 +0200 (MET DST)
From:   liste@hgfelger.de
Received: from localhost (hgfelger@localhost)
	by frog.athome (8.9.3/8.9.3) with ESMTP id AAA00478;
	Mon, 23 Oct 2000 00:22:40 +0200
X-Authentication-Warning: frog.athome: hgfelger owned process doing -bs
Date:   Mon, 23 Oct 2000 00:22:34 +0200 (CEST)
X-Sender: hgfelger@frog.athome
Reply-To: hgfelger@hgfelger.de
To:     Henner Eisen <eis@baty.hanse.de>
cc:     netdev@oss.sgi.com, i4ldeveloper@listserv.isdn4linux.de
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
In-Reply-To: <200010212316.BAA21084@baty.hanse.de>
Message-ID: <Pine.LNX.4.10.10010230021110.474-100000@frog.athome>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salut Henner,
On Sun, 22 Oct 2000, Henner Eisen wrote:
>     liste> reported Warning: kfree_skb passed an skb still on a list
>     liste> (from <isdn_ppp_push_higher+0x298>).
>.... 
> BTW, is your kernel SMP?
no, not the hardware, nor the kernel-compile-option. :-(

- -- 
1024D/339FD693 Hartwig Felger <hgfelger@hgfelger.de>
Key fingerprint = FB2F 3EE9 345A D55B 6FF2  0EC1 F5B0 684F 339F D693
For the pulic keys, please visit my page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE582iv9bBoTzOf1pMRAnE0AJ906a0v6MvuEeKNQaXhpVjCBOdvRACg7ksT
OgCOj667p8HxWL/Jam/BaHM=
=CRUa
-----END PGP SIGNATURE-----


From owner-netdev@oss.sgi.com Sun Oct 22 19:09:12 2000
Received:  by oss.sgi.com id <S553788AbQJWCJD>;
	Sun, 22 Oct 2000 19:09:03 -0700
Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]:12186 "EHLO
        shonan.sfc.wide.ad.jp") by oss.sgi.com with ESMTP
	id <S553690AbQJWCIe>; Sun, 22 Oct 2000 19:08:34 -0700
Received: from YUMIKO.sfc.wide.ad.jp (ppp3ppp16.sfc.keio.ac.jp [133.27.12.82])
	by shonan.sfc.wide.ad.jp (8.9.3+3.2W/3.7Wpl2-shonan) with ESMTP id LAA03715
	for <netdev@oss.sgi.com>; Mon, 23 Oct 2000 11:08:30 +0900 (JST)
	(envelope-from sekiya@sfc.wide.ad.jp)
Date:   Mon, 23 Oct 2000 11:08:02 +0900
Message-ID: <ulmvge2d9.wl@YUMIKO.sfc.wide.ad.jp>
From:   Yuji Sekiya <sekiya@sfc.wide.ad.jp>
To:     netdev@oss.sgi.com
Subject: ZERONET and BADCLASS
User-Agent: Wanderlust/1.1.1 (Purple Rain) REMI/1.14.1 (=?ISO-8859-4?Q?Mus?=
 =?ISO-8859-4?Q?higawa=F2sugi?=) Chao/1.14.0 (Momoyama) APEL/10.2
 Emacs/20.7 (i386-*-nt5.0.2195) MULE/4.1 (AOI) Meadow/IPv6-1.13 Beta1++
 (TANAHASHI:61)
Organization: Keio University
MIME-Version: 1.0 (generated by REMI 1.14.1 - =?ISO-8859-4?Q?=22Mushigawa=F2?=
 =?ISO-8859-4?Q?sugi=22?=)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Hello,

I have a simple question. 
In net/ipv4/fib_frontend.c:inet_addr_type(),

        if (ZERONET(addr) || BADCLASS(addr))
                return RTN_BROADCAST;
        if (MULTICAST(addr))
                return RTN_MULTICAST;

the kernel treats ZERONET(0.0.0.0/8) and BADCLASS(240.0.0.0/4) as
boradcast address.

I think these address classes are invalid address classes
Then is it correct to treat them as broadcast address ?

Sorry if I am missing someting...

-- Yuji Sekiya


From owner-netdev@oss.sgi.com Mon Oct 23 03:29:47 2000
Received:  by oss.sgi.com id <S553786AbQJWK3h>;
	Mon, 23 Oct 2000 03:29:37 -0700
Received: from mail.zmailer.org ([194.252.70.162]:26632 "EHLO zmailer.org")
	by oss.sgi.com with ESMTP id <S553770AbQJWK3X>;
	Mon, 23 Oct 2000 03:29:23 -0700
Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org))
	by mail.zmailer.org id <S378233AbQJWK3D>;
	Mon, 23 Oct 2000 13:29:03 +0300
Date:	Mon, 23 Oct 2000 13:29:03 +0300
From:	Matti Aarnio <matti.aarnio@zmailer.org>
To:	vlan@Scry.WANfear.com
Cc:	netdev@oss.sgi.com
Subject: Re: STP and vlan_hard_start
Message-ID: <20001023132903.O7196@mea-ext.zmailer.org>
References: <39F33A68.3B16380A@candelatech.com> <Pine.LNX.4.21.0010231108390.22560-100000@mara.math.leidenuniv.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.21.0010231108390.22560-100000@mara.math.leidenuniv.nl>; from buytenh@gnu.org on Mon, Oct 23, 2000 at 11:08:54AM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Oct 23, 2000 at 11:08:54AM +0200, Lennert Buytenhek wrote:
> Does anyone have an idea whether mbufs (BSD) solve this problem in a
> neater way?

  ["this" = need to increase header space when pushing in new hard
   headers, like 4 byte VLAN tag header. ]

  "yes"  -- but you have to pay for fragment overhead there anyway,
  and I seem to recall that there are network interface cards which
  will require coalescing the fragments into contiguous buffer for
  DMA assisted sending.   There are smarter hardware in the market
  which support scatter-grather from such fragments, e.g. all modern
  stuff. But the more you give them fragments, the more you give
  unwanted overhead for them.

  Also SysV STREAMS are capable to handle pushing such pre-header into
  a packet without needing space pre-allocation like our SKB scheme
  calls for.


  There is a general layering problem.

  Upper levels which allocate the skb for transmit have no actual clue
  regarding what lower level system their buffer will use when going out.

  The (IPv4-)TCP code does allocate:
	MAX_TCP_HEADER + 15 + tp->mss_cache
  for each full outgoing frame.

  There  MAX_TCP_HEADER = 128 + MAX_HEADER

  There MAX_HEADER = LL_MAX_HEADER + 48 (if IPv6 or IPIP support is defined)
		   = LL_MAX_HEADER + 0  (if neither of those)

  And LL_MAX_HEADER = 96 (if with AX25)
		    = 48 (if no AX25, but have TokenRing)
		    = 32 (in all other cases)

  Then happens  tcp_alloc_skb() (which calls  alloc_skb()  plus does
  assorted TCP related tricks), and after further TCP tricks, call
  for   skb_reserve(skb, MAX_TCP_HEADER)   is done.


  I really would like to see some mechanism by which we can register
  (properly layered) those varying header fields without need to do
  preprocessor gymnastics, like   include/linux/netdevice.h   has.

  That is, when I push in VLAN support module, I could instantly get
  4 extra bytes of hard-header-len into the upper layers.   Best if
  I would get that only for cases which are going out thru device
  where those bytes would be added, and not "just in case" for all.
  (That selective adding, of course, is layering violation.)

/Matti Aarnio

From owner-netdev@oss.sgi.com Mon Oct 23 07:37:00 2000
Received:  by oss.sgi.com id <S553797AbQJWOgu>;
	Mon, 23 Oct 2000 07:36:50 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:38925 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553793AbQJWOge>;
	Mon, 23 Oct 2000 07:36:34 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id SAA16504; Mon, 23 Oct 2000 18:36:23 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200010231436.SAA16504@ms2.inr.ac.ru>
Subject: Re: sin_zero (again)
To:     misiek@pld.ORG.PL (Arkadiusz Miskiewicz)
Date:   Mon, 23 Oct 2000 18:36:23 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20001020194622.A2958@pld.org.pl> from "Arkadiusz Miskiewicz" at Oct 20, 0 07:46:22 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 163       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> It's easy to repair so why don't fix it ?

Because... This is not a good question. 8)8)

I see no reasons not to fix this. Is it good answer? 8)

Alexey

From owner-netdev@oss.sgi.com Mon Oct 23 10:04:52 2000
Received:  by oss.sgi.com id <S553679AbQJWREc>;
	Mon, 23 Oct 2000 10:04:32 -0700
Received: from mail.zmailer.org ([194.252.70.162]:32520 "EHLO zmailer.org")
	by oss.sgi.com with ESMTP id <S553660AbQJWREN>;
	Mon, 23 Oct 2000 10:04:13 -0700
Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org))
	by mail.zmailer.org id <S378233AbQJWRD6>;
	Mon, 23 Oct 2000 20:03:58 +0300
Date:	Mon, 23 Oct 2000 20:03:58 +0300
From:	Matti Aarnio <matti.aarnio@zmailer.org>
To:	Ben Greear <greearb@candelatech.com>
Cc:	netdev@oss.sgi.com
Subject: Re: STP and vlan_hard_start
Message-ID: <20001023200358.S7196@mea-ext.zmailer.org>
References: <39F33A68.3B16380A@candelatech.com> <Pine.LNX.4.21.0010231108390.22560-100000@mara.math.leidenuniv.nl> <20001023132903.O7196@mea-ext.zmailer.org> <39F46463.9C5B392D@candelatech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <39F46463.9C5B392D@candelatech.com>; from greearb@candelatech.com on Mon, Oct 23, 2000 at 09:16:35AM -0700
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Oct 23, 2000 at 09:16:35AM -0700, Ben Greear wrote:
... 
> >   4 extra bytes of hard-header-len into the upper layers.   Best if
> >   I would get that only for cases which are going out thru device
> >   where those bytes would be added, and not "just in case" for all.
> >   (That selective adding, of course, is layering violation.)
> 
> You need the outgoing pkt length, which means you must know your device
> at the time you allocate the SKB.  That doesn't really seem feasible to me.
> (Routing, bridging, pkt-filtering, all make 'routing' decisions after the
> SKB has been created...)

	Indeed.  That is why I used term "layering violation"...

	What I do think is worth considering:

	Have the  LL_MAX_HEADER  replaced with a global integer, and
	adding support for some protocol (registering a protocol in)
	would be allowed to (with a spinlock?) increment the value
	in there.  (It is "a read-a-lot, modify rarely", after all,
	thus having ATOMIC access there is serious waste of cycles.)


	Thus e.g. IPv6 activation would push in its own additional
	48 byte reservation into the pile for L3 use.  (Perhaps
	the TCP frame allocation should be split into IPv4 and IPv6
	versions with appropriate max sizes for IP and TCP,
	respectively.)

	Because all frames can not be added on top of each other,
	some smarter way to stack them would be nice for easier
	protocol plugin registration. 

	Layer 2:

		ENET - type/NSAP [ - VLAN ] -  ...
		ENET [ - VLAN ] - type/NSAP -  ...
		TR   - NSAP [ - VLAN ] -       ...
		FDDI - NSAP [ - VLAN ] -       ...
		HDLC [ - PPP / CISCO HDLC ] -  ...
		AX25 ...
		PPP  ...
		FrameRelay - NSAP - bridged-ENET - ...
		ATM-AAL5 - PPP - ...
		ATM-AAL5 - NSAP - PPP ...

	Layer 3:

		IPv4 - TCP/UDP/ICMP
		IPv6 - TCP/UDP/ICMP
		...


	During initialization each subsystem would register how much they
	need header space each, and the registration routine would go
	thru the entire registered facility space, adding up stackable
	chains at each level remembering maximums.

	The final allocation space at L3 would then be the sum of  Layer 2
	and Layer 3 maximums (maybe, maybe not..)


	Thinking more of it, there propably should be two integers,
	one for use at Layer2 receivers, which would be used to reserve
	space into beginning of the frame so that of it becomes bridged
	(or routed) to other Layer2 device, there would be space for it.
	(For example:  PPP framed IP packet coming in and going out
	 thru FDDI NSAP frames, or thru AX25 UI frames.)

	The more I think of these, the more I think we need to start
	supporting MBUF-like block chains.  Their uses should be
	seriously deprecated and most commonly used protocols and frames
	should still use pre-allocation of "hard header", but rarer
	things could do chains.

> Ben
> -- 
> Ben Greear (greearb@candelatech.com)  http://www.candelatech.com

/Matti Aarnio

From owner-netdev@oss.sgi.com Mon Oct 23 17:43:47 2000
Received:  by oss.sgi.com id <S553711AbQJXAn1>;
	Mon, 23 Oct 2000 17:43:27 -0700
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:10001 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S553695AbQJXAnX>;
	Mon, 23 Oct 2000 17:43:23 -0700
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.9.3) with ESMTP id SAA07930;
	Mon, 23 Oct 2000 18:36:44 -0700
Message-ID: <39F4E7AC.BB5D451E@candelatech.com>
Date:   Mon, 23 Oct 2000 18:36:44 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Matti Aarnio <matti.aarnio@zmailer.org>
CC:     netdev@oss.sgi.com
Subject: Re: STP and vlan_hard_start
References: <39F33A68.3B16380A@candelatech.com> <Pine.LNX.4.21.0010231108390.22560-100000@mara.math.leidenuniv.nl> <20001023132903.O7196@mea-ext.zmailer.org> <39F46463.9C5B392D@candelatech.com> <20001023200358.S7196@mea-ext.zmailer.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Matti Aarnio wrote:
> 
> On Mon, Oct 23, 2000 at 09:16:35AM -0700, Ben Greear wrote:
> ...
> > >   4 extra bytes of hard-header-len into the upper layers.   Best if
> > >   I would get that only for cases which are going out thru device
> > >   where those bytes would be added, and not "just in case" for all.
> > >   (That selective adding, of course, is layering violation.)
> >
> > You need the outgoing pkt length, which means you must know your device
> > at the time you allocate the SKB.  That doesn't really seem feasible to me.
> > (Routing, bridging, pkt-filtering, all make 'routing' decisions after the
> > SKB has been created...)
> 
>         Indeed.  That is why I used term "layering violation"...
> 
>         What I do think is worth considering:
> 
>         Have the  LL_MAX_HEADER  replaced with a global integer, and
>         adding support for some protocol (registering a protocol in)
>         would be allowed to (with a spinlock?) increment the value
>         in there.  (It is "a read-a-lot, modify rarely", after all,
>         thus having ATOMIC access there is serious waste of cycles.)

So, you get a pkt coming in, and then add a protocol, then then try to
egress the pkt over the new protocol.  It's now the wrong size, because it was created before
the proto was initialized.

This isn't too likely to happen, perhaps...but it would still require
a lot of defensive coding that may not currently be in place.

>         Because all frames can not be added on top of each other,
>         some smarter way to stack them would be nice for easier
>         protocol plugin registration.

What does this really gain you?
More efficient use of memory? (Perhaps, but not much I think...)
Performance? (I doubt it, can someone offer an argument in favor?)
I don't think it's simpler, though it may make that one particular
place in netdevice.h cleaner.


>         The more I think of these, the more I think we need to start
>         supporting MBUF-like block chains.  Their uses should be
>         seriously deprecated and most commonly used protocols and frames
>         should still use pre-allocation of "hard header", but rarer
>         things could do chains.

Chopping up your memory into blocks (which means allocating each block, right?)
does not seem any more efficient that just leaving adequate space at the
beginning of the skb, as is possible now.  It would probably suck as far as
the cache is concerned too...

Ben

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Tue Oct 24 02:54:52 2000
Received:  by oss.sgi.com id <S553739AbQJXJym>;
	Tue, 24 Oct 2000 02:54:42 -0700
Received: from gleb.nbase.co.il ([194.90.136.56]:5129 "EHLO gleb.nbase.co.il")
	by oss.sgi.com with ESMTP id <S553725AbQJXJyT>;
	Tue, 24 Oct 2000 02:54:19 -0700
Received: (from gleb@localhost)
	by gleb.nbase.co.il (8.11.1/8.11.1/Debian 8.11.0-6) id e9O9rWR09972;
	Tue, 24 Oct 2000 11:53:32 +0200
From:   Gleb Natapov <gleb@nbase.co.il>
Date:   Tue, 24 Oct 2000 11:53:32 +0200
To:     Ben Greear <greearb@candelatech.com>
Cc:     Matti Aarnio <matti.aarnio@zmailer.org>, netdev@oss.sgi.com
Subject: Re: STP and vlan_hard_start
Message-ID: <20001024115332.B8243@nbase.co.il>
References: <39F33A68.3B16380A@candelatech.com> <Pine.LNX.4.21.0010231108390.22560-100000@mara.math.leidenuniv.nl> <20001023132903.O7196@mea-ext.zmailer.org> <39F46463.9C5B392D@candelatech.com> <20001023200358.S7196@mea-ext.zmailer.org> <39F4E7AC.BB5D451E@candelatech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <39F4E7AC.BB5D451E@candelatech.com>; from greearb@candelatech.com on Mon, Oct 23, 2000 at 06:36:44PM -0700
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Oct 23, 2000 at 06:36:44PM -0700, Ben Greear wrote:
> Matti Aarnio wrote:
[snip]
> >         The more I think of these, the more I think we need to start
> >         supporting MBUF-like block chains.  Their uses should be
> >         seriously deprecated and most commonly used protocols and frames
> >         should still use pre-allocation of "hard header", but rarer
> >         things could do chains.
> 
> Chopping up your memory into blocks (which means allocating each block, right?)
> does not seem any more efficient that just leaving adequate space at the
> beginning of the skb, as is possible now.  

 The problem is that you not always know how much is "adequate space" and if you didn't guess
correct you must allocate new buffer and copy all data from old one.

--
			Gleb.

From owner-netdev@oss.sgi.com Tue Oct 24 03:53:43 2000
Received:  by oss.sgi.com id <S553736AbQJXKxX>;
	Tue, 24 Oct 2000 03:53:23 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:50677 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S553655AbQJXKxF>;
	Tue, 24 Oct 2000 03:53:05 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id GAA06128;
	Tue, 24 Oct 2000 06:53:00 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id GAA29220;
	Tue, 24 Oct 2000 06:52:59 -0400 (EDT)
Date:   Tue, 24 Oct 2000 06:52:59 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Gleb Natapov <gleb@nbase.co.il>
cc:     Ben Greear <greearb@candelatech.com>,
        Matti Aarnio <matti.aarnio@zmailer.org>, netdev@oss.sgi.com
Subject: Re: STP and vlan_hard_start
In-Reply-To: <20001024115332.B8243@nbase.co.il>
Message-ID: <Pine.GSO.4.20.0010240643450.29181-100000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



On Tue, 24 Oct 2000, Gleb Natapov wrote:

>  The problem is that you not always know how much is "adequate space" and if you didn't guess
> correct you must allocate new buffer and copy all data from old one.

This is a common problem in a lot protocols which insert headers
in between at the lower layers. It becomes even more sexy when this
inserted layer is variable (eg an MPLS label-stack).
The brute force way is to ofcourse always allocate a size equal to the
path MTU.  
How about using some of the route flags to indicate that a particular
path has a requirement like this? so then you know apriori what the extra
gap is and can allocate for it. Add to this a generic call:
skb_add_to_header(skb,offset,length,value) and you are almost set.

cheers,
jamal


From owner-netdev@oss.sgi.com Wed Oct 25 08:26:51 2000
Received:  by oss.sgi.com id <S553812AbQJYP0b>;
	Wed, 25 Oct 2000 08:26:31 -0700
Received: from Cantor.suse.de ([194.112.123.193]:14610 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553809AbQJYP0S>;
	Wed, 25 Oct 2000 08:26:18 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP id 738871E0C6
	for <netdev@oss.sgi.com>; Wed, 25 Oct 2000 17:26:16 +0200 (MEST)
Received: from Thor.suse.de (Thor.suse.de [10.10.11.1])
	by Hermes.suse.de (Postfix) with ESMTP id 65D2C3E46E
	for <netdev@oss.sgi.com>; Wed, 25 Oct 2000 17:26:16 +0200 (MEST)
Received: from nectarine.suse.de (nectarine.suse.de [10.10.1.156])
	by Thor.suse.de (Postfix) with ESMTP id 5874E8D82F
	for <netdev@oss.sgi.com>; Wed, 25 Oct 2000 17:26:16 +0200 (CEST)
Received: (from olh@localhost)
	by nectarine.suse.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id e9PFPsN06972
	for netdev@oss.sgi.com; Wed, 25 Oct 2000 17:25:54 +0200
Date:   Wed, 25 Oct 2000 17:25:54 +0200
From:   Olaf Hering <olh@suse.de>
To:     netdev@oss.sgi.com
Subject: plip broken on ppc
Message-ID: <20001025172554.A6885@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi,

the plip driver doesnt work on ppc. The ip address of the local machine
is screwed up. Any hints how to fix it?
The kernel is a 2.2.17pre6.

ifconfig plip0 192.168.2.2 irq 9 io_addr 0x3bc pointopoint 192.168.2.1 up

local:

plip0     Link encap:Ethernet  HWaddr FC:FC:C0:A8:02:02  
          inet addr:0.0.3.188  P-t-P:192.168.2.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 

banana:/usr/src/OLAF/linux-2.2.16.SuSE # netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.10.0.0       0.0.0.0         255.255.0.0     U         0 0          0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0         10.10.0.8       0.0.0.0         UG        0 0          0 eth0


That works fine on an i386 machine.
No special dmesg output.

parport0: PC-style at 0x3bc, irq 9 [SPP]
parport_probe: failed
parport0: no IEEE-1284 device present.
NET3 PLIP version 2.3-parport gniibe@mri.co.jp
plip0: Parallel port at 0x3bc, using IRQ 9




Gruss Olaf

-- 
 $ man clone

BUGS
       Main feature not yet implemented...

From owner-netdev@oss.sgi.com Wed Oct 25 13:29:22 2000
Received:  by oss.sgi.com id <S553714AbQJYU3C>;
	Wed, 25 Oct 2000 13:29:02 -0700
Received: from ferret.cs.fiu.edu ([131.94.125.231]:13065 "EHLO
        ferret.cs.fiu.edu") by oss.sgi.com with ESMTP id <S553665AbQJYU2z>;
	Wed, 25 Oct 2000 13:28:55 -0700
Received: from cs.fiu.edu (IDENT:esj@heaven.cs.fiu.edu [131.94.133.12]) by ferret.cs.fiu.edu (8.9.3/FIU-CS-1.2) with ESMTP id QAA21961 for <netdev@oss.sgi.com>; Wed, 25 Oct 2000 16:28:44 -0400
Message-Id: <200010252028.QAA21961@ferret.cs.fiu.edu>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-0.27
To:     netdev@oss.sgi.com
Subject: Netflow version 5 export FROM linux router
X-image-url: http://www.cs.fiu.edu/~esj/ejthumb.gif
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 25 Oct 2000 20:28:43 +0000
From:   "Eric S. Johnson" <esj@cs.fiu.edu>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Has anyone looked into what would be needed to export version 5 
netflow information from a linux box acting as a router? Anyone
working on such a project?

E


From owner-netdev@oss.sgi.com Wed Oct 25 13:55:04 2000
Received:  by oss.sgi.com id <S553746AbQJYUyx>;
	Wed, 25 Oct 2000 13:54:53 -0700
Received: from mx3out.umbc.edu ([130.85.253.53]:10712 "EHLO mx3out.umbc.edu")
	by oss.sgi.com with ESMTP id <S553681AbQJYUyf>;
	Wed, 25 Oct 2000 13:54:35 -0700
Received: from porty (andy@proxima.cs.umbc.edu [130.85.100.17])
	by mx3out.umbc.edu (8.9.3/8.9.3) with SMTP id QAA23893
	for <netdev@oss.sgi.com>; Wed, 25 Oct 2000 16:54:11 -0400 (EDT)
Date:   Wed, 25 Oct 2000 16:54:07 -0400
From:   "Lego Andy" <andy@x0.org>
To:     netdev@oss.sgi.com
Subject: Listening on Broadcast address
Message-Id: <20001025165407.2c3bfce8.andy@x0.org>
X-Mailer: Sylpheed version 0.4.2 (GTK+ 1.2.8; Linux 2.2.17; i686)
Organization: X0
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

My Linux box stopped listening to broadcast addresses.
It worked yesterday, but today it did not work.
Same program works fine on other machines.

It does send stuff on broadcast and if I do that, I can also
listening, but it does not receive anything from outside.

Is there any suggestion?

			Andy

From owner-netdev@oss.sgi.com Wed Oct 25 14:25:23 2000
Received:  by oss.sgi.com id <S553759AbQJYVZE>;
	Wed, 25 Oct 2000 14:25:04 -0700
Received: from mx2out.umbc.edu ([130.85.253.52]:10152 "EHLO mx2out.umbc.edu")
	by oss.sgi.com with ESMTP id <S553742AbQJYVYr>;
	Wed, 25 Oct 2000 14:24:47 -0700
Received: from porty (andy@proxima.cs.umbc.edu [130.85.100.17])
	by mx2out.umbc.edu (8.9.3/8.9.3) with SMTP id RAA00056;
	Wed, 25 Oct 2000 17:24:24 -0400 (EDT)
Date:   Wed, 25 Oct 2000 17:24:24 -0400
From:   "Lego Andy" <andy@x0.org>
To:     Felix von Leitner <usenet-20001025@fefe.de>
Cc:     netdev@oss.sgi.com
Subject: Re: Listening on Broadcast address
Message-Id: <20001025172424.0ea79139.andy@x0.org>
In-Reply-To: <20001025211936.29583.qmail@convergence.de>
References: <20001025165407.2c3bfce8.andy@x0.org>
	<20001025211936.29583.qmail@convergence.de>
X-Mailer: Sylpheed version 0.4.2 (GTK+ 1.2.8; Linux 2.2.17; i686)
Organization: X0
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> > It does send stuff on broadcast and if I do that, I can also
> > listening, but it does not receive anything from outside.
> 
> > Is there any suggestion?
> 
> You probably changed your broadcast or netmask setting.

No, but thanks for the help.

This is my ifconfig:
eth0      Link encap:Ethernet  HWaddr 00:10:7A:15:7B:4E  
          inet addr:xx.xx.xx.17  Bcast:xx.xx.xx.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14220 errors:0 dropped:0 overruns:0 frame:0
          TX packets:124 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          Interrupt:9 Base address:0x880

The other machine is:
xx.xx.xx-1.66

The third machine is:
xx.xx.xx.202

			Andy

From owner-netdev@oss.sgi.com Wed Oct 25 16:48:05 2000
Received:  by oss.sgi.com id <S553768AbQJYXrp>;
	Wed, 25 Oct 2000 16:47:45 -0700
Received: from Cantor.suse.de ([194.112.123.193]:30217 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553648AbQJYXrT>;
	Wed, 25 Oct 2000 16:47:19 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP id 6A2C01E224
	for <netdev@oss.sgi.com>; Thu, 26 Oct 2000 01:47:17 +0200 (MEST)
Received: from Thor.suse.de (Thor.suse.de [10.10.11.1])
	by Hermes.suse.de (Postfix) with ESMTP id 380393E46F
	for <netdev@oss.sgi.com>; Thu, 26 Oct 2000 01:47:17 +0200 (MEST)
Received: from nectarine.suse.de (nectarine.suse.de [10.10.1.156])
	by Thor.suse.de (Postfix) with ESMTP id 747818D82F
	for <netdev@oss.sgi.com>; Thu, 26 Oct 2000 01:47:16 +0200 (CEST)
Received: (from olh@localhost)
	by nectarine.suse.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id e9PNkah30732
	for netdev@oss.sgi.com; Thu, 26 Oct 2000 01:46:36 +0200
Date:   Thu, 26 Oct 2000 01:46:36 +0200
From:   Olaf Hering <olh@suse.de>
To:     netdev@oss.sgi.com
Subject: Re: plip broken on ppc
Message-ID: <20001026014636.A30696@suse.de>
References: <20001025172554.A6885@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001025172554.A6885@suse.de>; from olh@suse.de on Wed, Oct 25, 2000 at 05:25:54PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Wed, Oct 25, Olaf Hering wrote:

> ifconfig plip0 192.168.2.2 irq 9 io_addr 0x3bc pointopoint 192.168.2.1 up
                             ^^^^^^^^^^^^^^^^^^^
looks like yast does something wrong here, these stuff works for i386,
but not for ppc. I removed these io parts and it works now.



Gruss Olaf

-- 
 $ man clone

BUGS
       Main feature not yet implemented...

From owner-netdev@oss.sgi.com Wed Oct 25 20:44:15 2000
Received:  by oss.sgi.com id <S553825AbQJZDnz>;
	Wed, 25 Oct 2000 20:43:55 -0700
Received: from laurin.munich.netsurf.de ([194.64.166.1]:17886 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S553776AbQJZDn0>; Wed, 25 Oct 2000 20:43:26 -0700
Received: from fred.muc.de (noidentity@ns1088.munich.netsurf.de [195.180.235.88])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id FAA04198;
	Thu, 26 Oct 2000 05:43:23 +0200 (MET DST)
Received: by fred.muc.de (Postfix, from userid 500)
	id 9D8F2E3913; Thu, 26 Oct 2000 05:47:45 +0200 (CEST)
Date:   Thu, 26 Oct 2000 05:47:45 +0200
From:   Andi Kleen <ak@muc.de>
To:     Olaf Hering <olh@suse.de>
Cc:     netdev@oss.sgi.com
Subject: Re: plip broken on ppc
Message-ID: <20001026054745.A26867@fred.muc.de>
References: <20001025172554.A6885@suse.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="SUOF0GtieIMvvwua"
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20001025172554.A6885@suse.de>; from olh@suse.de on Wed, Oct 25, 2000 at 05:27:51PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii

On Wed, Oct 25, 2000 at 05:27:51PM +0200, Olaf Hering wrote:
> Hi,
> 
> the plip driver doesnt work on ppc. The ip address of the local machine
> is screwed up. Any hints how to fix it?
> The kernel is a 2.2.17pre6.


The attached two patches (to the kernel and ifconfig) fix it.

It was not really a PPC bug, but an appletalk bug.


-Andi


--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=ifconfig-err-fix

--- ifconfig.c-o	Thu Oct 26 04:16:30 2000
+++ ifconfig.c	Thu Oct 26 04:25:39 2000
@@ -356,12 +356,13 @@
 		    goterr = 1;
 		} else {
 		    if (ioctl(skfd, SIOCGIFMAP, &ifr) < 0) {
+			perror("port: SIOCGIFMAP"); 
 			goterr = 1;
 			continue;
 		    }
 		    ifr.ifr_map.port = newport;
 		    if (ioctl(skfd, SIOCSIFMAP, &ifr) < 0) {
-			perror("SIOCSIFMAP");
+			perror("port: SIOCSIFMAP");
 			goterr = 1;
 		    }
 		}
@@ -562,12 +563,14 @@
 	    if (*++spp == NULL)
 		usage();
 	    if (ioctl(skfd, SIOCGIFMAP, &ifr) < 0) {
+		fprintf(stderr, "mem_start: SIOCGIFMAP: %s\n", strerror(errno)); 
+		spp++; 
 		goterr = 1;
 		continue;
 	    }
 	    ifr.ifr_map.mem_start = strtoul(*spp, NULL, 0);
 	    if (ioctl(skfd, SIOCSIFMAP, &ifr) < 0) {
-		fprintf(stderr, "SIOCSIFMAP: %s\n", strerror(errno));
+		fprintf(stderr, "mem_start: SIOCSIFMAP: %s\n", strerror(errno));
 		goterr = 1;
 	    }
 	    spp++;
@@ -577,12 +580,14 @@
 	    if (*++spp == NULL)
 		usage();
 	    if (ioctl(skfd, SIOCGIFMAP, &ifr) < 0) {
+		fprintf(stderr, "io_addr: SIOCGIFMAP: %s\n", strerror(errno)); 
+		spp++; 
 		goterr = 1;
 		continue;
 	    }
 	    ifr.ifr_map.base_addr = strtol(*spp, NULL, 0);
 	    if (ioctl(skfd, SIOCSIFMAP, &ifr) < 0) {
-		fprintf(stderr, "SIOCSIFMAP: %s\n", strerror(errno));
+		fprintf(stderr, "io_addr: SIOCSIFMAP: %s\n", strerror(errno));
 		goterr = 1;
 	    }
 	    spp++;
@@ -592,12 +597,14 @@
 	    if (*++spp == NULL)
 		usage();
 	    if (ioctl(skfd, SIOCGIFMAP, &ifr) < 0) {
+		fprintf(stderr, "irq: SIOCGIFMAP: %s\n", strerror(errno)); 
 		goterr = 1;
+		spp++; 
 		continue;
 	    }
 	    ifr.ifr_map.irq = atoi(*spp);
 	    if (ioctl(skfd, SIOCSIFMAP, &ifr) < 0) {
-		fprintf(stderr, "SIOCSIFMAP: %s\n", strerror(errno));
+		fprintf(stderr, "irq: SIOCSIFMAP: %s\n", strerror(errno));
 		goterr = 1;
 	    }
 	    spp++;

--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=atalk-fix

--- linux-work/net/appletalk/ddp.c-DEVERR	Thu Sep 14 13:41:23 2000
+++ linux-work/net/appletalk/ddp.c	Thu Oct 26 04:40:48 2000
@@ -2083,22 +2083,6 @@
 		case SIOCDARP:	/* proxy AARP */
 			return (atif_ioctl(cmd,(void *)arg));
 
-		/*
-		 * Physical layer ioctl calls
-		 */
-		case SIOCSIFLINK:
-		case SIOCGIFHWADDR:
-		case SIOCSIFHWADDR:
-		case SIOCGIFFLAGS:
-		case SIOCSIFFLAGS:
-		case SIOCGIFMTU:
-		case SIOCGIFCONF:
-		case SIOCADDMULTI:
-		case SIOCDELMULTI:
-		case SIOCGIFCOUNT:
-		case SIOCGIFINDEX:
-		case SIOCGIFNAME:
-			return ((dev_ioctl(cmd,(void *) arg)));
 
 		case SIOCSIFMETRIC:
 		case SIOCSIFBRDADDR:
@@ -2111,7 +2095,7 @@
 			return (-EINVAL);
 
 		default:
-			return (-EINVAL);
+			return dev_ioctl(cmd, (void *) arg); 
 	}
 
 	return (put_user(amount, (int *)arg));
--- linux-work/net/ipv4/af_inet.c-DEVERR	Fri Oct 20 06:19:38 2000
+++ linux-work/net/ipv4/af_inet.c	Thu Oct 26 04:35:53 2000
@@ -956,7 +956,7 @@
 
 			if (sk->prot->ioctl==NULL || (err=sk->prot->ioctl(sk, cmd, arg))==-ENOIOCTLCMD)
 				return(dev_ioctl(cmd,(void *) arg));		
-			return err;
+			return -EINVAL;
 	}
 	/*NOTREACHED*/
 	return(0);

--SUOF0GtieIMvvwua--

From owner-netdev@oss.sgi.com Wed Oct 25 21:23:05 2000
Received:  by oss.sgi.com id <S553828AbQJZEWz>;
	Wed, 25 Oct 2000 21:22:55 -0700
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:26640 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S553781AbQJZEW3>;
	Wed, 25 Oct 2000 21:22:29 -0700
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.9.3) with ESMTP id WAA22620;
	Wed, 25 Oct 2000 22:16:03 -0700
Message-ID: <39F7BE13.A905E557@candelatech.com>
Date:   Wed, 25 Oct 2000 22:16:03 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>,
        linux-net <linux-net@vger.kernel.org>,
        VLAN Mailing List <vlan@Scry.WANfear.com>
Subject: Question on dev_add_pack (kernel 2.2.17)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Strange things are happening in VLAN land for me at the moment, and
I think that this might be part of the problem.  VLAN code can now
mangle packets (the header only..but still..)

So, it seems that it should be at the end of the list of packet_types
in the hash.  However, the dev_add_pack always places it on the front.

So, how am I meant to place it on the back?  Add another method?  Add
a flag to this method to specify head/tail?

>From dev.c:

/*
 *	Add a protocol ID to the list. Now that the input handler is
 *	smarter we can dispense with all the messy stuff that used to be
 *	here.
 *
 *	BEWARE!!! Protocol handlers, mangling input packets,
 *	MUST BE last in hash buckets and checking protocol handlers
 *	MUST start from promiscous ptype_all chain in net_bh.
 *	It is true now, do not change it.
 *	Explantion follows: if protocol handler, mangling packet, will
 *	be the first on list, it is not able to sense, that packet
 *	is cloned and should be copied-on-write, so that it will
 *	change it and subsequent readers will get broken packet.
 *							--ANK (980803)
 */
 void dev_add_pack(struct packet_type *pt)
{
...


Thanks,
Ben

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Sat Oct 28 20:30:05 2000
Received:  by oss.sgi.com id <S553821AbQJ2D3z>;
	Sat, 28 Oct 2000 20:29:55 -0700
Received: from brutus.conectiva.com.br ([200.250.58.146]:58364 "EHLO
        brutus.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553744AbQJ2D3d>; Sat, 28 Oct 2000 20:29:33 -0700
Received: from localhost (riel@localhost)
	by brutus.conectiva.com.br (8.11.1/8.11.1) with ESMTP id e9T3Sc407269;
	Sun, 29 Oct 2000 01:28:38 -0200
X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs
Date:   Sun, 29 Oct 2000 01:28:38 -0200 (BRDT)
From:   Rik van Riel <riel@conectiva.com.br>
X-Sender: riel@duckman.distro.conectiva
To:     davem@redhat.com
cc:     linux-kernel@vger.kernel.org, netdev <netdev@oss.sgi.com>
Subject: tcp.c::wait_for_tcp_memory() buggy ?
Message-ID: <Pine.LNX.4.21.0010290122050.4224-100000@duckman.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi Davem,

I can't quite put my finger on what wait_for_tcp_memory() is
supposed to do, but the code looks EXTREMELY suspect and I've
had a report of somebody looping in the for(;;) loop in that
function without ever exiting and getting his TCP connection
stuck there...

Also, the locking inside the loop seems fragile, to say the
least.

from tcp.c:

  865         if (tcp_memory_free(sk) && !vm_wait)
  866                 break;

  880         release_sock(sk);
  881         if (!tcp_memory_free(sk) || vm_wait)
  882                 current_timeo = schedule_timeout(current_timeo);
  883         lock_sock(sk);

Here we hold the lock for the entire loop (meaning that
other people cannot make the exit condition on line 865
come true.

Except for doing a test on tcp_memory_free(sk), where we
do NOT hold the lock we're so dutifully clinging to during
the rest of the loop...

As I said, I can't put my finger down on what exactly is
wrong, but this code looks subtle enough that, together
with the bugreport I got (on IRC), I have the feeling that
it just _can't_ be right ...

regards, 

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/


From owner-netdev@oss.sgi.com Sun Oct 29 00:12:16 2000
Received:  by oss.sgi.com id <S553823AbQJ2HL4>;
	Sun, 29 Oct 2000 00:11:56 -0700
Received: from Cantor.suse.de ([194.112.123.193]:42507 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553818AbQJ2HLa>;
	Sun, 29 Oct 2000 00:11:30 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id E05391E09C; Sun, 29 Oct 2000 08:11:28 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 61F193E488; Sun, 29 Oct 2000 08:11:28 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 7CF1A2F300; Sun, 29 Oct 2000 08:11:23 +0100 (MET)
Date:   Sun, 29 Oct 2000 08:11:23 +0100
From:   Andi Kleen <ak@suse.de>
To:     Rik van Riel <riel@conectiva.com.br>
Cc:     davem@redhat.com, linux-kernel@vger.kernel.org,
        netdev <netdev@oss.sgi.com>
Subject: Re: tcp.c::wait_for_tcp_memory() buggy ?
Message-ID: <20001029081123.A18126@gruyere.muc.suse.de>
References: <Pine.LNX.4.21.0010290122050.4224-100000@duckman.distro.conectiva>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.21.0010290122050.4224-100000@duckman.distro.conectiva>; from riel@conectiva.com.br on Sun, Oct 29, 2000 at 01:28:38AM -0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sun, Oct 29, 2000 at 01:28:38AM -0200, Rik van Riel wrote:
> Except for doing a test on tcp_memory_free(sk), where we
> do NOT hold the lock we're so dutifully clinging to during
> the rest of the loop...

And rechecking it later while holding the loop on the next iteration.

Also usually the caller also does a check again and iterates as needed.

> 
> As I said, I can't put my finger down on what exactly is
> wrong, but this code looks subtle enough that, together
> with the bugreport I got (on IRC), I have the feeling that
> it just _can't_ be right ...

With the right setup of multiple threads writing all the time
on a single socket you could probably starve one, making it loop forever here.
(it does not try to be fair) 



-Andi


From owner-netdev@oss.sgi.com Sun Oct 29 12:09:29 2000
Received:  by oss.sgi.com id <S553750AbQJ2UJT>;
	Sun, 29 Oct 2000 12:09:19 -0800
Received: from mail0.atl.bellsouth.net ([205.152.0.27]:42924 "EHLO
        mail0.atl.bellsouth.net") by oss.sgi.com with ESMTP
	id <S553742AbQJ2UI7>; Sun, 29 Oct 2000 12:08:59 -0800
Received: from mandrakesoft.com ([66.20.73.115])
	by mail0.atl.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id PAA11266;
	Sun, 29 Oct 2000 15:04:20 -0500 (EST)
Message-ID: <39FC83CD.B10BF08D@mandrakesoft.com>
Date:   Sun, 29 Oct 2000 15:08:45 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     pavel rabel <pavel@web.sajt.cz>
CC:     linux-net@vger.kernel.org, p_gortmaker@yahoo.com,
        netdev@oss.sgi.com,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.21.0010300344130.6792-100000@web.sajt.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

pavel rabel wrote:
> There are three drivers for n2k cards. One is MCA only, one is PCI only,
> and the then the third one (ne.c) is both ISA and PCI. I think the ISA
> driver should be ISA only, as is described in Documentation and in config
> help. So I removed PCI code from ne.c to have ISA only driver. It
> gets a bit smaller, although I am not sure whether more code can be
> removed.

This change sounds ok to me, if noone else objects.  (I added to the CC
a bit)  I saw that code, and was thinking about doing the same thing
myself.  ne2k-pci.c definitely has changes which are not included in
ne.c, and it seems silly to duplicate ne2000 PCI support.

Regards,

	Jeff


P.S.  Pavel, for the future, patches made with "diff -u" are preferred.

-- 
Jeff Garzik             | "Mind if I drive?"  -Sam
Building 1024           | "Not if you don't mind me clawing at the
MandrakeSoft            |  dash and shrieking like a cheerleader."
                        |                     -Max

From owner-netdev@oss.sgi.com Sun Oct 29 12:33:39 2000
Received:  by oss.sgi.com id <S553776AbQJ2Ud3>;
	Sun, 29 Oct 2000 12:33:29 -0800
Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:10288 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S553746AbQJ2UdF>;
	Sun, 29 Oct 2000 12:33:05 -0800
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 13pz9c-0006Jh-00; Sun, 29 Oct 2000 20:34:08 +0000
Subject: Re: [patch] NE2000
To:     jgarzik@mandrakesoft.com (Jeff Garzik)
Date:   Sun, 29 Oct 2000 20:34:06 +0000 (GMT)
Cc:     pavel@web.sajt.cz (pavel rabel), linux-net@vger.kernel.org,
        p_gortmaker@yahoo.com, netdev@oss.sgi.com,
        linux-kernel@vger.kernel.org (Linux Kernel Mailing List)
In-Reply-To: <39FC83CD.B10BF08D@mandrakesoft.com> from "Jeff Garzik" at Oct 29, 2000 03:08:45 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E13pz9c-0006Jh-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> This change sounds ok to me, if noone else objects.  (I added to the CC
> a bit)  I saw that code, and was thinking about doing the same thing
> myself.  ne2k-pci.c definitely has changes which are not included in
> ne.c, and it seems silly to duplicate ne2000 PCI support.

Unless there are any cards that need the bug workarounds in ne.c for use
on PCI then I see no problem. I've not heard of any. 


From owner-netdev@oss.sgi.com Sun Oct 29 23:03:31 2000
Received:  by oss.sgi.com id <S553845AbQJ3HDV>;
	Sun, 29 Oct 2000 23:03:21 -0800
Received: from chiara.elte.hu ([157.181.150.200]:36358 "HELO chiara.elte.hu")
	by oss.sgi.com with SMTP id <S553841AbQJ3HDQ>;
	Sun, 29 Oct 2000 23:03:16 -0800
Received: by chiara.elte.hu (Postfix, from userid 17806)
	id A61E8184D; Mon, 30 Oct 2000 08:03:13 +0100 (CET)
Date:   Mon, 30 Oct 2000 09:13:02 +0100 (CET)
From:   Ingo Molnar <mingo@elte.hu>
Reply-To: mingo@elte.hu
To:     Rik van Riel <riel@conectiva.com.br>
Cc:     "David S. Miller" <davem@redhat.com>, linux-kernel@vger.kernel.org,
        netdev <netdev@oss.sgi.com>
Subject: Re: tcp.c::wait_for_tcp_memory() buggy ?
In-Reply-To: <Pine.LNX.4.21.0010290122050.4224-100000@duckman.distro.conectiva>
Message-ID: <Pine.LNX.4.21.0010300905320.1270-100000@elte.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


On Sun, 29 Oct 2000, Rik van Riel wrote:

> I can't quite put my finger on what wait_for_tcp_memory() is supposed
> to do, [...]

it's waiting for TCP output packets to be processed. This is a TCP
protocol detail and is not connected to VM issues. The function name might
be a bit misleading, it could be 'tcp_write_possible()', or
'tcp_wmem_free()'.

> [...] but the code looks EXTREMELY suspect and I've had a report of
> somebody looping in the for(;;) loop in that function without ever
> exiting and getting his TCP connection stuck there...

as far as i understand, this can happen if another host (for whatever
reason) does not process the TCP output packets this host has sent.

> Also, the locking inside the loop seems fragile, to say the
> least.
> 
> from tcp.c:
> 
>   865         if (tcp_memory_free(sk) && !vm_wait)
>   866                 break;
> 
>   880         release_sock(sk);
>   881         if (!tcp_memory_free(sk) || vm_wait)
>   882                 current_timeo = schedule_timeout(current_timeo);
>   883         lock_sock(sk);
> 
> Here we hold the lock for the entire loop (meaning that
> other people cannot make the exit condition on line 865
> come true.

we do not keep the lock for the entire loop, we schedule away on line 882
with the socket lock dropped. This is a pretty standard (and safe) locking
technique.

> Except for doing a test on tcp_memory_free(sk), where we
> do NOT hold the lock we're so dutifully clinging to during
> the rest of the loop...

well, thats the point of the socket lock - we can access socket data
structures almost only via the socket lock.

	Ingo


From owner-netdev@oss.sgi.com Mon Oct 30 01:25:11 2000
Received:  by oss.sgi.com id <S553753AbQJ3JZC>;
	Mon, 30 Oct 2000 01:25:02 -0800
Received: from smtp1.mail.yahoo.com ([128.11.69.60]:25616 "HELO
        smtp1.mail.yahoo.com") by oss.sgi.com with SMTP id <S553696AbQJ3JYq>;
	Mon, 30 Oct 2000 01:24:46 -0800
Received: from ppp069.muskoka.com (HELO gromit.hairy.org) (199.212.175.99)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 30 Oct 2000 09:24:43 -0000
X-Apparently-From: <p?gortmaker@yahoo.com>
Message-ID: <39FD3CB6.2F641BBF@yahoo.com>
Date:   Mon, 30 Oct 2000 04:17:42 -0500
From:   Paul Gortmaker <p_gortmaker@yahoo.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.17 i486)
MIME-Version: 1.0
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
CC:     pavel rabel <pavel@web.sajt.cz>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.21.0010300344130.6792-100000@web.sajt.cz> <39FC83CD.B10BF08D@mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Jeff Garzik wrote:
> 
> pavel rabel wrote:
> > help. So I removed PCI code from ne.c to have ISA only driver. It
> 
> This change sounds ok to me, if noone else objects.  (I added to the CC
> a bit)  I saw that code, and was thinking about doing the same thing
> myself.  ne2k-pci.c definitely has changes which are not included in
> ne.c, and it seems silly to duplicate ne2000 PCI support.

Actually if you look at the archives (ID 39A3A608.1F984C60@yahoo.com)
you will see that I've stated this will be done for 2.5 a couple of
months ago.  (Which is also why PCI support in ne.c hasn't tracked that
of ne2k-pci.c - I want to avoid encouraging new PCI users of ne.c)

There is no urgency in trying to squeeze a patch like this in the back
door of a 2.4.0 release.  For example, there are people out there now
who are using the ne.c driver to run both ISA and PCI cards in the same 
box without having to use 2 different drivers.  We can wait until 2.5.0
to break their .config file.

[ I've several other 8390 related patches I've been sitting on - trying
to not contribute to the delay of 2.4.0 unless explicitly asked, such
as the 8390.h get_module_symbol deletion.  Other 8390 patches I have 
are a separated Tx timeout for 8390.c, kill off dev->rmem_start/end 
and use ioremap() where required, and replace old check/request_region()
with code that makes use of the newer resource structures. ]

Good to know people are still keeping an eye out for dead code though...

Thanks,
Paul.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


From owner-netdev@oss.sgi.com Mon Oct 30 07:00:13 2000
Received:  by oss.sgi.com id <S553858AbQJ3PAD>;
	Mon, 30 Oct 2000 07:00:03 -0800
Received: from web.sajt.cz ([212.71.160.9]:6921 "EHLO web.sajt.cz")
	by oss.sgi.com with ESMTP id <S553840AbQJ3O7t>;
	Mon, 30 Oct 2000 06:59:49 -0800
Received: from localhost (pavel@localhost)
	by web.sajt.cz (8.11.0/8.10.2/sajt.cz) with ESMTP id e9UEwXD13179;
	Mon, 30 Oct 2000 15:58:33 +0100
Date:   Mon, 30 Oct 2000 15:58:33 +0100 (CET)
From:   pavel rabel <pavel@web.sajt.cz>
To:     Paul Gortmaker <p_gortmaker@yahoo.com>
cc:     Jeff Garzik <jgarzik@mandrakesoft.com>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] NE2000
In-Reply-To: <39FD3CB6.2F641BBF@yahoo.com>
Message-ID: <Pine.LNX.4.21.0010301551060.13164-100000@web.sajt.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



On Mon, 30 Oct 2000, Paul Gortmaker wrote:

> There is no urgency in trying to squeeze a patch like this in the back
> door of a 2.4.0 release.  For example, there are people out there now
> who are using the ne.c driver to run both ISA and PCI cards in the same 
> box without having to use 2 different drivers.  We can wait until 2.5.0
> to break their .config file.

I am not quite sure how it will work when you try to use both ne.c and
ne2k-pci drivers in the same box. Which driver will be used for PCI card?
Maybe people with both cards are forced to use inferior driver for PCI
card.

Pavel Rabel



From owner-netdev@oss.sgi.com Mon Oct 30 11:31:27 2000
Received:  by oss.sgi.com id <S553885AbQJ3TbS>;
	Mon, 30 Oct 2000 11:31:18 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:38407 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S553883AbQJ3Ta7>;
	Mon, 30 Oct 2000 11:30:59 -0800
Received: from mandrakesoft.com ([66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id OAA06999;
	Mon, 30 Oct 2000 14:29:58 -0500
Message-ID: <39FDCC17.4C8B8074@mandrakesoft.com>
Date:   Mon, 30 Oct 2000 14:29:27 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Paul Gortmaker <p_gortmaker@yahoo.com>
CC:     pavel rabel <pavel@web.sajt.cz>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.21.0010300344130.6792-100000@web.sajt.cz> <39FC83CD.B10BF08D@mandrakesoft.com> <39FD3CB6.2F641BBF@yahoo.com>
Content-Type: multipart/mixed;
 boundary="------------6333FE7853C048EC25185249"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This is a multi-part message in MIME format.
--------------6333FE7853C048EC25185249
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Gortmaker wrote:
> There is no urgency in trying to squeeze a patch like this in the back
> door of a 2.4.0 release.  For example, there are people out there now
> who are using the ne.c driver to run both ISA and PCI cards in the same
> box without having to use 2 different drivers.  We can wait until 2.5.0
> to break their .config file.

IMNSHO this is a bug, though...

Do a diff of the key 8390 interface routines in ne.c, and ne2k-pci.c. 
Ignoring the inb_p and outb_p differences, there are distinct advantages
to using ne2k-pci.c on with an NE2000 PCI board.

Since ne2k-pci.c supports all boards ne.c does, and includes some fixes
that ne.c does not, it seems like removing the PCI support in ne.c is a
bug fix change.

It looks like ne2k-pci.c does need a HZ scaling fixing from ne.c
though...

	Jeff



-- 
Jeff Garzik             | "Mind if I drive?"  -Sam
Building 1024           | "Not if you don't mind me clawing at the
MandrakeSoft            |  dash and shrieking like a cheerleader."
                        |                     -Max
--------------6333FE7853C048EC25185249
Content-Type: text/plain; charset=us-ascii;
 name="ne2000.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ne2000.diff"

--- /g/g/tmp/1	Mon Oct 30 14:22:41 2000
+++ /g/g/tmp/2	Mon Oct 30 14:22:58 2000
@@ -1,60 +1,61 @@
 /* Hard reset the card.  This used to pause for the same period that a
    8390 reset command required, but that shouldn't be necessary. */
-
-static void ne_reset_8390(struct net_device *dev)
+static void
+ne2k_pci_reset_8390(struct net_device *dev)
 {
 	unsigned long reset_start_time = jiffies;
 
-	if (ei_debug > 1)
-		printk(KERN_DEBUG "resetting the 8390 t=%ld...", jiffies);
+	if (debug > 1) printk("%s: Resetting the 8390 t=%ld...",
+						  dev->name, jiffies);
 
-	/* DON'T change these to inb_p/outb_p or reset will fail on clones. */
 	outb(inb(NE_BASE + NE_RESET), NE_BASE + NE_RESET);
 
 	ei_status.txing = 0;
 	ei_status.dmaing = 0;
 
 	/* This check _should_not_ be necessary, omit eventually. */
-	while ((inb_p(NE_BASE+EN0_ISR) & ENISR_RESET) == 0)
-		if (jiffies - reset_start_time > 2*HZ/100) {
-			printk(KERN_WARNING "%s: ne_reset_8390() did not complete.\n", dev->name);
+	while ((inb(NE_BASE+EN0_ISR) & ENISR_RESET) == 0)
+		if (jiffies - reset_start_time > 2) {
+			printk("%s: ne2k_pci_reset_8390() did not complete.\n", dev->name);
 			break;
 		}
-	outb_p(ENISR_RESET, NE_BASE + EN0_ISR);	/* Ack intr. */
+	outb(ENISR_RESET, NE_BASE + EN0_ISR);	/* Ack intr. */
 }
 
 /* Grab the 8390 specific header. Similar to the block_input routine, but
    we don't need to be concerned with ring wrap as the header will be at
    the start of a page, so we optimize accordingly. */
 
-static void ne_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr, int ring_page)
+static void
+ne2k_pci_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr, int ring_page)
 {
-	int nic_base = dev->base_addr;
 
-	/* This *shouldn't* happen. If it does, it's the last thing you'll see */
+	long nic_base = dev->base_addr;
 
-	if (ei_status.dmaing) 
-	{
-		printk(KERN_EMERG "%s: DMAing conflict in ne_get_8390_hdr "
+	/* This *shouldn't* happen. If it does, it's the last thing you'll see */
+	if (ei_status.dmaing) {
+		printk("%s: DMAing conflict in ne2k_pci_get_8390_hdr "
 			"[DMAstat:%d][irqlock:%d].\n",
 			dev->name, ei_status.dmaing, ei_status.irqlock);
 		return;
 	}
 
 	ei_status.dmaing |= 0x01;
-	outb_p(E8390_NODMA+E8390_PAGE0+E8390_START, nic_base+ NE_CMD);
-	outb_p(sizeof(struct e8390_pkt_hdr), nic_base + EN0_RCNTLO);
-	outb_p(0, nic_base + EN0_RCNTHI);
-	outb_p(0, nic_base + EN0_RSARLO);		/* On page boundary */
-	outb_p(ring_page, nic_base + EN0_RSARHI);
-	outb_p(E8390_RREAD+E8390_START, nic_base + NE_CMD);
+	outb(E8390_NODMA+E8390_PAGE0+E8390_START, nic_base+ NE_CMD);
+	outb(sizeof(struct e8390_pkt_hdr), nic_base + EN0_RCNTLO);
+	outb(0, nic_base + EN0_RCNTHI);
+	outb(0, nic_base + EN0_RSARLO);		/* On page boundary */
+	outb(ring_page, nic_base + EN0_RSARHI);
+	outb(E8390_RREAD+E8390_START, nic_base + NE_CMD);
 
-	if (ei_status.word16)
+	if (ei_status.ne2k_flags & ONLY_16BIT_IO) {
 		insw(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr)>>1);
-	else
-		insb(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr));
+	} else {
+		*(u32*)hdr = le32_to_cpu(inl(NE_BASE + NE_DATAPORT));
+		le16_to_cpus(&hdr->count);
+	}
 
-	outb_p(ENISR_RDC, nic_base + EN0_ISR);	/* Ack intr. */
+	outb(ENISR_RDC, nic_base + EN0_ISR);	/* Ack intr. */
 	ei_status.dmaing &= ~0x01;
 }
 
@@ -63,172 +64,116 @@
    The NEx000 doesn't share the on-board packet memory -- you have to put
    the packet out through the "remote DMA" dataport using outb. */
 
-static void ne_block_input(struct net_device *dev, int count, struct sk_buff *skb, int ring_offset)
+static void
+ne2k_pci_block_input(struct net_device *dev, int count, struct sk_buff *skb, int ring_offset)
 {
-#ifdef NE_SANITY_CHECK
-	int xfer_count = count;
-#endif
-	int nic_base = dev->base_addr;
+	long nic_base = dev->base_addr;
 	char *buf = skb->data;
 
 	/* This *shouldn't* happen. If it does, it's the last thing you'll see */
-	if (ei_status.dmaing) 
-	{
-		printk(KERN_EMERG "%s: DMAing conflict in ne_block_input "
+	if (ei_status.dmaing) {
+		printk("%s: DMAing conflict in ne2k_pci_block_input "
 			"[DMAstat:%d][irqlock:%d].\n",
 			dev->name, ei_status.dmaing, ei_status.irqlock);
 		return;
 	}
 	ei_status.dmaing |= 0x01;
-	outb_p(E8390_NODMA+E8390_PAGE0+E8390_START, nic_base+ NE_CMD);
-	outb_p(count & 0xff, nic_base + EN0_RCNTLO);
-	outb_p(count >> 8, nic_base + EN0_RCNTHI);
-	outb_p(ring_offset & 0xff, nic_base + EN0_RSARLO);
-	outb_p(ring_offset >> 8, nic_base + EN0_RSARHI);
-	outb_p(E8390_RREAD+E8390_START, nic_base + NE_CMD);
-	if (ei_status.word16) 
-	{
+	if (ei_status.ne2k_flags & ONLY_32BIT_IO)
+		count = (count + 3) & 0xFFFC;
+	outb(E8390_NODMA+E8390_PAGE0+E8390_START, nic_base+ NE_CMD);
+	outb(count & 0xff, nic_base + EN0_RCNTLO);
+	outb(count >> 8, nic_base + EN0_RCNTHI);
+	outb(ring_offset & 0xff, nic_base + EN0_RSARLO);
+	outb(ring_offset >> 8, nic_base + EN0_RSARHI);
+	outb(E8390_RREAD+E8390_START, nic_base + NE_CMD);
+
+	if (ei_status.ne2k_flags & ONLY_16BIT_IO) {
 		insw(NE_BASE + NE_DATAPORT,buf,count>>1);
-		if (count & 0x01) 
-		{
+		if (count & 0x01) {
 			buf[count-1] = inb(NE_BASE + NE_DATAPORT);
-#ifdef NE_SANITY_CHECK
-			xfer_count++;
-#endif
 		}
 	} else {
-		insb(NE_BASE + NE_DATAPORT, buf, count);
+		insl(NE_BASE + NE_DATAPORT, buf, count>>2);
+		if (count & 3) {
+			buf += count & ~3;
+			if (count & 2)
+				*((u16*)buf)++ = le16_to_cpu(inw(NE_BASE + NE_DATAPORT));
+			if (count & 1)
+				*buf = inb(NE_BASE + NE_DATAPORT);
 	}
-
-#ifdef NE_SANITY_CHECK
-	/* This was for the ALPHA version only, but enough people have
-	   been encountering problems so it is still here.  If you see
-	   this message you either 1) have a slightly incompatible clone
-	   or 2) have noise/speed problems with your bus. */
-
-	if (ei_debug > 1) 
-	{
-		/* DMA termination address check... */
-		int addr, tries = 20;
-		do {
-			/* DON'T check for 'inb_p(EN0_ISR) & ENISR_RDC' here
-			   -- it's broken for Rx on some cards! */
-			int high = inb_p(nic_base + EN0_RSARHI);
-			int low = inb_p(nic_base + EN0_RSARLO);
-			addr = (high << 8) + low;
-			if (((ring_offset + xfer_count) & 0xff) == low)
-				break;
-		} while (--tries > 0);
-	 	if (tries <= 0)
-			printk(KERN_WARNING "%s: RX transfer address mismatch,"
-				"%#4.4x (expected) vs. %#4.4x (actual).\n",
-				dev->name, ring_offset + xfer_count, addr);
 	}
-#endif
-	outb_p(ENISR_RDC, nic_base + EN0_ISR);	/* Ack intr. */
+
+	outb(ENISR_RDC, nic_base + EN0_ISR);	/* Ack intr. */
 	ei_status.dmaing &= ~0x01;
 }
 
-static void ne_block_output(struct net_device *dev, int count,
+static void
+ne2k_pci_block_output(struct net_device *dev, int count,
 		const unsigned char *buf, const int start_page)
 {
-	int nic_base = NE_BASE;
+	long nic_base = NE_BASE;
 	unsigned long dma_start;
-#ifdef NE_SANITY_CHECK
-	int retries = 0;
-#endif
 
-	/* Round the count up for word writes.  Do we need to do this?
-	   What effect will an odd byte count have on the 8390?
-	   I should check someday. */
-	   
-	if (ei_status.word16 && (count & 0x01))
+	/* On little-endian it's always safe to round the count up for
+	   word writes. */
+	if (ei_status.ne2k_flags & ONLY_32BIT_IO)
+		count = (count + 3) & 0xFFFC;
+	else
+		if (count & 0x01)
 		count++;
 
 	/* This *shouldn't* happen. If it does, it's the last thing you'll see */
-	if (ei_status.dmaing) 
-	{
-		printk(KERN_EMERG "%s: DMAing conflict in ne_block_output."
+	if (ei_status.dmaing) {
+		printk("%s: DMAing conflict in ne2k_pci_block_output."
 			"[DMAstat:%d][irqlock:%d]\n",
 			dev->name, ei_status.dmaing, ei_status.irqlock);
 		return;
 	}
 	ei_status.dmaing |= 0x01;
 	/* We should already be in page 0, but to be safe... */
-	outb_p(E8390_PAGE0+E8390_START+E8390_NODMA, nic_base + NE_CMD);
-
-#ifdef NE_SANITY_CHECK
-retry:
-#endif
+	outb(E8390_PAGE0+E8390_START+E8390_NODMA, nic_base + NE_CMD);
 
 #ifdef NE8390_RW_BUGFIX
 	/* Handle the read-before-write bug the same way as the
 	   Crynwr packet driver -- the NatSemi method doesn't work.
 	   Actually this doesn't always work either, but if you have
 	   problems with your NEx000 this is better than nothing! */
-	   
-	outb_p(0x42, nic_base + EN0_RCNTLO);
-	outb_p(0x00,   nic_base + EN0_RCNTHI);
-	outb_p(0x42, nic_base + EN0_RSARLO);
-	outb_p(0x00, nic_base + EN0_RSARHI);
-	outb_p(E8390_RREAD+E8390_START, nic_base + NE_CMD);
-	/* Make certain that the dummy read has occurred. */
-	udelay(6);
+	outb(0x42, nic_base + EN0_RCNTLO);
+	outb(0x00, nic_base + EN0_RCNTHI);
+	outb(0x42, nic_base + EN0_RSARLO);
+	outb(0x00, nic_base + EN0_RSARHI);
+	outb(E8390_RREAD+E8390_START, nic_base + NE_CMD);
 #endif
-
-	outb_p(ENISR_RDC, nic_base + EN0_ISR);
+	outb(ENISR_RDC, nic_base + EN0_ISR);
 
 	/* Now the normal output. */
-	outb_p(count & 0xff, nic_base + EN0_RCNTLO);
-	outb_p(count >> 8,   nic_base + EN0_RCNTHI);
-	outb_p(0x00, nic_base + EN0_RSARLO);
-	outb_p(start_page, nic_base + EN0_RSARHI);
-
-	outb_p(E8390_RWRITE+E8390_START, nic_base + NE_CMD);
-	if (ei_status.word16) {
+	outb(count & 0xff, nic_base + EN0_RCNTLO);
+	outb(count >> 8,   nic_base + EN0_RCNTHI);
+	outb(0x00, nic_base + EN0_RSARLO);
+	outb(start_page, nic_base + EN0_RSARHI);
+	outb(E8390_RWRITE+E8390_START, nic_base + NE_CMD);
+	if (ei_status.ne2k_flags & ONLY_16BIT_IO) {
 		outsw(NE_BASE + NE_DATAPORT, buf, count>>1);
 	} else {
-		outsb(NE_BASE + NE_DATAPORT, buf, count);
+		outsl(NE_BASE + NE_DATAPORT, buf, count>>2);
+		if (count & 3) {
+			buf += count & ~3;
+			if (count & 2)
+				outw(cpu_to_le16(*((u16*)buf)++), NE_BASE + NE_DATAPORT);
+		}
 	}
 
 	dma_start = jiffies;
 
-#ifdef NE_SANITY_CHECK
-	/* This was for the ALPHA version only, but enough people have
-	   been encountering problems so it is still here. */
-	
-	if (ei_debug > 1) 
-	{
-		/* DMA termination address check... */
-		int addr, tries = 20;
-		do {
-			int high = inb_p(nic_base + EN0_RSARHI);
-			int low = inb_p(nic_base + EN0_RSARLO);
-			addr = (high << 8) + low;
-			if ((start_page << 8) + count == addr)
-				break;
-		} while (--tries > 0);
-
-		if (tries <= 0) 
-		{
-			printk(KERN_WARNING "%s: Tx packet transfer address mismatch,"
-				"%#4.4x (expected) vs. %#4.4x (actual).\n",
-				dev->name, (start_page << 8) + count, addr);
-			if (retries++ == 0)
-				goto retry;
-		}
-	}
-#endif
-
-	while ((inb_p(nic_base + EN0_ISR) & ENISR_RDC) == 0)
-		if (jiffies - dma_start > 2*HZ/100) {		/* 20ms */
-			printk(KERN_WARNING "%s: timeout waiting for Tx RDC.\n", dev->name);
-			ne_reset_8390(dev);
+	while ((inb(nic_base + EN0_ISR) & ENISR_RDC) == 0)
+		if (jiffies - dma_start > 2) { 			/* Avoid clock roll-over. */
+			printk("%s: timeout waiting for Tx RDC.\n", dev->name);
+			ne2k_pci_reset_8390(dev);
 			NS8390_init(dev,1);
 			break;
 		}
 
-	outb_p(ENISR_RDC, nic_base + EN0_ISR);	/* Ack intr. */
+	outb(ENISR_RDC, nic_base + EN0_ISR);	/* Ack intr. */
 	ei_status.dmaing &= ~0x01;
 	return;
 }

--------------6333FE7853C048EC25185249--


From owner-netdev@oss.sgi.com Mon Oct 30 11:36:17 2000
Received:  by oss.sgi.com id <S553888AbQJ3TgH>;
	Mon, 30 Oct 2000 11:36:07 -0800
Received: from 134-ZARA-X27.libre.retevision.es ([62.82.240.134]:31500 "EHLO
        head.redvip.net") by oss.sgi.com with ESMTP id <S553886AbQJ3Tfz>;
	Mon, 30 Oct 2000 11:35:55 -0800
Received: from quartz.redvip.net
	([192.168.0.3] helo=zaralinux.com ident=coma)
	by head.redvip.net with esmtp (Exim 3.16 #1)
	id 13qCdt-0008Nh-00; Mon, 30 Oct 2000 11:58:17 +0100
Message-ID: <39FD5433.587FF7C6@zaralinux.com>
Date:   Mon, 30 Oct 2000 11:57:55 +0100
From:   Jorge Nerin <comandante@zaralinux.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-test10 i586)
X-Accept-Language: es-ES, es, en
MIME-Version: 1.0
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
CC:     Jeff Garzik <jgarzik@mandrakesoft.com>,
        pavel rabel <pavel@web.sajt.cz>, linux-net@vger.kernel.org,
        p_gortmaker@yahoo.com, netdev@oss.sgi.com,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] NE2000
References: <E13pz9c-0006Jh-00@the-village.bc.nu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Alan Cox wrote:
> 
> > This change sounds ok to me, if noone else objects.  (I added to the CC
> > a bit)  I saw that code, and was thinking about doing the same thing
> > myself.  ne2k-pci.c definitely has changes which are not included in
> > ne.c, and it seems silly to duplicate ne2000 PCI support.
> 
> Unless there are any cards that need the bug workarounds in ne.c for use
> on PCI then I see no problem. I've not heard of any.
> 

Ok, I reported it several times, but it gets ignored. I have a Realtek
8029 (ne2k-pci), and with both drivers ne and ne2k-pci I can easily get
it stuck by doing a ping -f to a host in the local net, and sometimes it
happens doing copies to/from nfs shared resources.

rmmod & insmod don't cure the problem, it seems that no interrupts are
delivered from the card, and there are no log messages, so a reboot is
needed to restore net access.

System is dual 2x200mmx 96Mb ide discs no interrupts shared, and as far
as I can remember all kernel from 2.2.x, 2.3.x up to 2.4.0-testx exhibit
this problem.

-- 
Jorge Nerin
<comandante@zaralinux.com>

From owner-netdev@oss.sgi.com Mon Oct 30 14:34:21 2000
Received:  by oss.sgi.com id <S553899AbQJ3WeM>;
	Mon, 30 Oct 2000 14:34:12 -0800
Received: from smtp2.Mountain.Net ([198.77.1.5]:50635 "EHLO
        nabiki.mountain.net") by oss.sgi.com with ESMTP id <S553892AbQJ3Wdz>;
	Mon, 30 Oct 2000 14:33:55 -0800
Received: from mountain.net (AM11-7.Huntington-WV.Mountain.Net [198.77.57.21])
	by nabiki.mountain.net (8.11.1/8.11.0) with ESMTP id e9UMXM230892;
	Mon, 30 Oct 2000 17:33:22 -0500
Message-ID: <39FDF518.A9F1204D@mountain.net>
Date:   Mon, 30 Oct 2000 17:24:24 -0500
From:   Tom Leete <tleete@mountain.net>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18pre13 i486)
X-Accept-Language: en-US,en-GB,en,fr,es,it,de,ru
MIME-Version: 1.0
To:     "David S. Miller" <davem@redhat.com>
CC:     linux-kernel@vger.kernel.org, netdev <netdev@oss.sgi.com>
Subject: [PATCH] ipv4 skbuff locking scope
Content-Type: multipart/mixed;
 boundary="------------F7235E45F57BA24361EDD4C3"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This is a multi-part message in MIME format.
--------------F7235E45F57BA24361EDD4C3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

This fixes tests of a socket buffer done without holding the
lock. tcp_data_wait() and wait_for_tcp_memory() both had
unguarded refs in their sleep conditionals.

Tom
--------------F7235E45F57BA24361EDD4C3
Content-Type: text/plain; charset=us-ascii;
 name="tcp.lock.scope.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="tcp.lock.scope.patch"

--- linux-2.4.0-test10-pre5/net/ipv4/tcp.c~	Sun Oct 29 01:21:09 2000
+++ linux/net/ipv4/tcp.c	Mon Oct 30 16:53:19 2000
@@ -204,6 +204,9 @@
  *		Andi Kleen 	:	Make poll agree with SIGIO
  *	Salvatore Sanfilippo	:	Support SO_LINGER with linger == 1 and
  *					lingertime == 0 (RFC 793 ABORT Call)
+ *              Tom Leete       :       Fix locking scope in
+ *                                      wait_for_tcp_memory, tcp_data_wait
+ *
  *					
  *		This program is free software; you can redistribute it and/or
  *		modify it under the terms of the GNU General Public License
@@ -871,10 +874,11 @@
 			break;
 		if (sk->err)
 			break;
-		release_sock(sk);
-		if (!tcp_memory_free(sk) || vm_wait)
+		if (!tcp_memory_free(sk) || vm_wait) {
+			release_sock(sk);
 			current_timeo = schedule_timeout(current_timeo);
-		lock_sock(sk);
+			lock_sock(sk);
+		}
 		if (vm_wait) {
 			if (timeo != MAX_SCHEDULE_TIMEOUT &&
 			    (timeo -= vm_wait-current_timeo) < 0)
@@ -1273,12 +1277,12 @@
 	__set_current_state(TASK_INTERRUPTIBLE);
 
 	set_bit(SOCK_ASYNC_WAITDATA, &sk->socket->flags);
-	release_sock(sk);
 
-	if (skb_queue_empty(&sk->receive_queue))
+	if (skb_queue_empty(&sk->receive_queue)){
+		release_sock(sk);
 		timeo = schedule_timeout(timeo);
-
-	lock_sock(sk);
+		lock_sock(sk);
+	}
 	clear_bit(SOCK_ASYNC_WAITDATA, &sk->socket->flags);
 
 	remove_wait_queue(sk->sleep, &wait);

--------------F7235E45F57BA24361EDD4C3--


From owner-netdev@oss.sgi.com Mon Oct 30 14:39:42 2000
Received:  by oss.sgi.com id <S553903AbQJ3WjW>;
	Mon, 30 Oct 2000 14:39:22 -0800
Received: from pizda.ninka.net ([216.101.162.242]:31361 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S553900AbQJ3WjI>;
	Mon, 30 Oct 2000 14:39:08 -0800
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id OAA02266;
	Mon, 30 Oct 2000 14:24:46 -0800
Date:   Mon, 30 Oct 2000 14:24:46 -0800
Message-Id: <200010302224.OAA02266@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     tleete@mountain.net
CC:     linux-kernel@vger.kernel.org, netdev@oss.sgi.com
In-reply-to: <39FDF518.A9F1204D@mountain.net> (message from Tom Leete on Mon,
	30 Oct 2000 17:24:24 -0500)
Subject: Re: [PATCH] ipv4 skbuff locking scope
References:  <39FDF518.A9F1204D@mountain.net>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: Mon, 30 Oct 2000 17:24:24 -0500
   From: Tom Leete <tleete@mountain.net>

   This fixes tests of a socket buffer done without holding the
   lock. tcp_data_wait() and wait_for_tcp_memory() both had
   unguarded refs in their sleep conditionals.

These are not buggy at all, see the discussion which took place here
over the past few days.

Look, if the sleep condition test "races" due to not holding the lock,
the schedule() just returns because if the sleep condidion test passes
then by definition this means we were also woken up, see?

BTW, while we're on the topic of people not understanding the
networking locking and proposing bogus patches, does anyone know who
sent the bogon IP tunneling locking "fixes" to Linus behind my back?

They were crap too, and I had to revert them in test10-pre7.  It's
another case of people just not understanding how the code works and
thus that it is correct without any changes.

Please send such fixes to me, and I'll set you straight with a
description as to why your change is unnecessary :-)

Later,
David S. Miller
davem@redhat.com


From owner-netdev@oss.sgi.com Mon Oct 30 19:41:42 2000
Received:  by oss.sgi.com id <S553904AbQJaDlW>;
	Mon, 30 Oct 2000 19:41:22 -0800
Received: from chac.inf.utfsm.cl ([200.1.19.54]:780 "EHLO chac.inf.utfsm.cl")
	by oss.sgi.com with ESMTP id <S553700AbQJaDk7>;
	Mon, 30 Oct 2000 19:40:59 -0800
Received: from sleipnir.valparaiso.cl (IDENT:root@sleipnir.valparaiso.cl [204.87.169.3])
	by chac.inf.utfsm.cl (8.9.3/8.9.3) with ESMTP id AAA03926;
	Tue, 31 Oct 2000 00:48:21 -0300
Received: from sleipnir.valparaiso.cl (vonbrand@localhost)
	by sleipnir.valparaiso.cl (8.11.1/8.11.1) with ESMTP id e9V2ftx29950;
	Mon, 30 Oct 2000 23:41:55 -0300
Message-Id: <200010310241.e9V2ftx29950@sleipnir.valparaiso.cl>
To:     "David S. Miller" <davem@redhat.com>
cc:     linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [PATCH] ipv4 skbuff locking scope 
In-Reply-To: Message from "David S. Miller" <davem@redhat.com> 
   of "Mon, 30 Oct 2000 14:24:46 -0800." <200010302224.OAA02266@pizda.ninka.net> 
Date:   Mon, 30 Oct 2000 23:41:55 -0300
From:   Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

"David S. Miller" <davem@redhat.com> said:

[...]

> Please send such fixes to me, and I'll set you straight with a
> description as to why your change is unnecessary :-)

Could you please Cc: them into the kernel? ;-)
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616


From owner-netdev@oss.sgi.com Mon Oct 30 19:59:52 2000
Received:  by oss.sgi.com id <S553911AbQJaD7n>;
	Mon, 30 Oct 2000 19:59:43 -0800
Received: from smtp2.Mountain.Net ([198.77.1.5]:36240 "EHLO
        nabiki.mountain.net") by oss.sgi.com with ESMTP id <S553906AbQJaD7Z>;
	Mon, 30 Oct 2000 19:59:25 -0800
Received: from mountain.net (AM11-23.Huntington-WV.Mountain.Net [198.77.57.37])
	by nabiki.mountain.net (8.11.1/8.11.0) with ESMTP id e9V3x6201644;
	Mon, 30 Oct 2000 22:59:07 -0500
Message-ID: <39FE39EF.62CC880B@mountain.net>
Date:   Mon, 30 Oct 2000 22:18:07 -0500
From:   Tom Leete <tleete@mountain.net>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.0-t10p5-kdb i486)
X-Accept-Language: en-US,en-GB,en,fr,es,it,de,ru
MIME-Version: 1.0
To:     "David S. Miller" <davem@redhat.com>
CC:     linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [PATCH] ipv4 skbuff locking scope
References: <39FDF518.A9F1204D@mountain.net> <200010302224.OAA02266@pizda.ninka.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

"David S. Miller" wrote:
> 
>    Date: Mon, 30 Oct 2000 17:24:24 -0500
>    From: Tom Leete <tleete@mountain.net>
> 
>    This fixes tests of a socket buffer done without holding the
>    lock. tcp_data_wait() and wait_for_tcp_memory() both had
>    unguarded refs in their sleep conditionals.
> 
> These are not buggy at all, see the discussion which took place here
> over the past few days.

I'll post traces privately. It was my lockups that got Rick
interested.
 
> Look, if the sleep condition test "races" due to not holding the lock,
> the schedule() just returns because if the sleep condidion test passes
> then by definition this means we were also woken up, see?

Would you explain what is accomplished by toggling the lock
every time through? What breaks by not doing so?

> BTW, while we're on the topic of people not understanding the
> networking locking and proposing bogus patches, does anyone know who
> sent the bogon IP tunneling locking "fixes" to Linus behind my back?

Not me, but see below.
 
> They were crap too, and I had to revert them in test10-pre7.  It's
> another case of people just not understanding how the code works and
> thus that it is correct without any changes.

If it's perfect why can't I use it without locking up the
machine? BTW, I'm currently running my patch. I can now
flood ping 100000 packets in either direction. With
unmodified tcp that is a red switcher (reliably hard locks
all i/o including the serial console).

> Please send such fixes to me, and I'll set you straight with a
> description as to why your change is unnecessary :-)

Perhaps that's why somebody wants to bypass you.

Tom Leete

From owner-netdev@oss.sgi.com Mon Oct 30 20:18:13 2000
Received:  by oss.sgi.com id <S553914AbQJaERx>;
	Mon, 30 Oct 2000 20:17:53 -0800
Received: from pizda.ninka.net ([216.101.162.242]:34945 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S553910AbQJaERm>;
	Mon, 30 Oct 2000 20:17:42 -0800
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id UAA05384;
	Mon, 30 Oct 2000 20:03:24 -0800
Date:   Mon, 30 Oct 2000 20:03:24 -0800
Message-Id: <200010310403.UAA05384@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     tleete@mountain.net
CC:     linux-kernel@vger.kernel.org, netdev@oss.sgi.com
In-reply-to: <39FE39EF.62CC880B@mountain.net> (message from Tom Leete on Mon,
	30 Oct 2000 22:18:07 -0500)
Subject: Re: [PATCH] ipv4 skbuff locking scope
References: <39FDF518.A9F1204D@mountain.net> <200010302224.OAA02266@pizda.ninka.net> <39FE39EF.62CC880B@mountain.net>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: Mon, 30 Oct 2000 22:18:07 -0500
   From: Tom Leete <tleete@mountain.net>

   > Look, if the sleep condition test "races" due to not holding the
   > lock, the schedule() just returns because if the sleep condidion
   > test passes then by definition this means we were also woken up,
   > see?

   Would you explain what is accomplished by toggling the lock every
   time through? What breaks by not doing so?

Incoming packets are not processed while the lock is held, they
get queued to the backlog.  When the lock is released, the backlog
packets get processed.

For a TCP sender, these backlog packets are ACKs making room in the
send buffer so that the application can put more data into the send
buffer.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Mon Oct 30 20:39:13 2000
Received:  by oss.sgi.com id <S553917AbQJaEjD>;
	Mon, 30 Oct 2000 20:39:03 -0800
Received: from saturn.cs.uml.edu ([129.63.8.2]:23559 "EHLO saturn.cs.uml.edu")
	by oss.sgi.com with ESMTP id <S553913AbQJaEiv>;
	Mon, 30 Oct 2000 20:38:51 -0800
Received: (from acahalan@localhost)
	by saturn.cs.uml.edu (8.11.0/8.10.0) id e9V4cOD299876;
	Mon, 30 Oct 2000 23:38:24 -0500 (EST)
From:   "Albert D. Cahalan" <acahalan@cs.uml.edu>
Message-Id: <200010310438.e9V4cOD299876@saturn.cs.uml.edu>
Subject: Re: [PATCH] ipv4 skbuff locking scope
To:     davem@redhat.com (David S. Miller)
Date:   Mon, 30 Oct 2000 23:38:24 -0500 (EST)
Cc:     tleete@mountain.net, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
In-Reply-To: <200010302224.OAA02266@pizda.ninka.net> from "David S. Miller" at Oct 30, 2000 02:24:46 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

David S. Miller writes:

> BTW, while we're on the topic of people not understanding the
> networking locking and proposing bogus patches, does anyone know who
> sent the bogon IP tunneling locking "fixes" to Linus behind my back?
...
> Please send such fixes to me, and I'll set you straight with a
> description as to why your change is unnecessary :-)

You can prevent future "fixes" by putting your comments in the code.

/*  like this  */

From owner-netdev@oss.sgi.com Tue Oct 31 07:56:00 2000
Received:  by oss.sgi.com id <S553744AbQJaPzk>;
	Tue, 31 Oct 2000 07:55:40 -0800
Received: from luna.tlmat.unican.es ([193.144.186.2]:20486 "EHLO
        luna.tlmat.unican.es") by oss.sgi.com with ESMTP id <S553720AbQJaPzL>;
	Tue, 31 Oct 2000 07:55:11 -0800
Received: from centauro (lira.tlmat.unican.es [193.144.186.27]) by luna.tlmat.unican.es with SMTP (8.7.6/8.7.1) id RAA06120 for <netdev@oss.sgi.com>; Tue, 31 Oct 2000 17:13:11 +0100 (MET)
Message-ID: <005b01c04352$eee46a60$1bba90c1@tlmat.unican.es>
From:   =?iso-8859-1?B?UmFt824gQWf8ZXJv?= <ramon@tlmat.unican.es>
To:     <netdev@oss.sgi.com>
Subject: Long idle time TCP connections
Date:   Tue, 31 Oct 2000 16:54:53 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0056_01C0435B.4A9A8760"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_0056_01C0435B.4A9A8760
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

    Hi all,

    Having measured some FTP transactions through a wireless channel =
(with errors) using tcpdump and xplot (to see the traces) I have found =
that in some ocasssions there are periods of time in which the server =
stops sending segments, with no aparent reason (i.e the transmission =
window is not full), I can't find the cause of these periods nor their =
duration, which seems to be incoherent.

    I'm working with kernel 2.2.14.

    I was wondering if some of you have noticed something similar and if =
you may explain me its causes.=20


Thank you very much in advance and best regards.

Ram=F3n


PD.- Please I wish to be personally CC'ed the answers/comments posted to =
the list in response to my posting



------=_NextPart_000_0056_01C0435B.4A9A8760
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Hi all,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Having measured some FTP =
transactions=20
through a wireless channel (with errors) using tcpdump and xplot (to see =
the=20
traces) I have found that in some ocasssions there are periods of time =
in which=20
the server stops sending segments, with no aparent reason (i.e the =
transmission=20
window is not full), I can't find the cause of these periods nor their =
duration,=20
which seems to be incoherent.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; I'm working with kernel=20
2.2.14.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; I was wondering if some of you =
have noticed=20
something similar and if you may explain me its causes. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Thank you very much in advance and best =
regards.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Ram=F3n</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>PD.- Please&nbsp;I wish to be personally CC'ed the=20
answers/comments posted to the list in response to&nbsp;my=20
posting<BR></DIV></FONT></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0056_01C0435B.4A9A8760--


From owner-netdev@oss.sgi.com Tue Oct 31 19:35:38 2000
Received:  by oss.sgi.com id <S553840AbQKADfS>;
	Tue, 31 Oct 2000 19:35:18 -0800
Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]:1197 "EHLO
        shaku.v6.linux.or.jp") by oss.sgi.com with ESMTP id <S553742AbQKADe4>;
	Tue, 31 Oct 2000 19:34:56 -0800
Received: from shaku.sfc.wide.ad.jp ([::1])
	by shaku.v6.linux.or.jp (8.11.0/3.7W) with ESMTP id eA13XZn26020
	for <netdev@oss.sgi.com>; Wed, 1 Nov 2000 12:33:35 +0900
Date:   Wed, 01 Nov 2000 12:33:35 +0900
Message-ID: <m3u29sqsc0.wl@shaku.sfc.wide.ad.jp>
From:   usagi-core <usagi-core@linux-ipv6.org>
To:     netdev@oss.sgi.com
Subject: [ANN] 1st release of USAGI IPv6 environment
User-Agent: Wanderlust/1.1.1 (Purple Rain) EMIKO/1.13.12 (Euglena
 sociabilis) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) APEL/10.2
 MULE XEmacs/21.1 (patch 9) (Canyonlands) (i686-pc-linux)
Organization: USAGI Project
Reply-To: usagi-core <usagi-core@linux-ipv6.org>
MIME-Version: 1.0 (generated by EMIKO 1.13.12 - "Euglena sociabilis")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


We are glad to announce the 1st release of USAGI Project. The "USAGI"
means UniverSAl playGround for Ipv6. It is the IPv6 development project
for Linux operating systems mainly.

As many other operating systems and routers, the Linux kernel has
its original IPv6 implementation.  However, the development was done
long time ago and the implementation is not up-to-dated. Many important
features such as IPsec and NDP are missing or miss-implemented.

Considering the situation, we have started USAGI Project with WIDE Project,
KAME Project and TAHI Project in August 2000. 

The USAGI Project is managed by volunteers and aims to provide
better IPv6 environment on Linux freely. We try to improve Linux kernel,
IPv6 related libraries and IPv6 applications.

Please visit http://www.linux-ipv6.org/ for further details.

Today, November 1st, we are glad to announce 1st official release from
USAGI Project. At the release, we include the following three packages.

- Linux Kernel-2.4.0-test9-usagi-20001101a
	Based on Linux Kernel-2.4.0-test9, we have improved and
	implemented
		+ better source address selection,
		+ ICMPv6 Node Information Queries,
		+ SNMP statistics per device,
		+ IPv6 khttpd,
		+ joining all-node multicast address on network devices and
		+ many bug fixes.

- glibc-2.1.3-usagi-20001101a
	Based on glibc-2.1.3, we have improved
		+ supporting sin6_scope_id,
		+ adding AF_ADDRCONFIG flag,
		+ some RFC2292 functions,
		+ adding getifaddrs API and
		+ some bug fixes.

- iputils-ss000418-usagi-20001101a
	Based on iputils-ss000418, we have improved
		+ supporting sin6_scope_id,
		+ IPMPv6 Node Information Queries and
		+ supporting Autoconfigure.

You can get above source codes from the following URL.
	ftp://ftp.linux-ipv6.org/pub/usagi/stable/patch/


USAGI Project will release snapshot codes on each two weeks and
after implementing some features, we will release stable codes.
We will announce latest information regarding releasing codes
via web page. Please check our web site.

We also provide the binary packages for some distributions.
Some of the binary packages have diffrent code version with original
USAGI code because of packaging policy. You can get the packages from
following sites.

Debian GNU/Linux 2.2 (potato)
	ftp://ftp.linux-ipv6.org/pub/usagi/stable/package/debian/

Kondara MNU/Linux (Jirai)
	ftp://ftp.linux-ipv6.org/pub/usagi/stable/package/kondara/

RedHat Linux 7.0
	ftp://ftp.linux-ipv6.org/pub/usagi/stable/package/redhat/

TurboLinux 6.0 (or later) (for Japanese version)
	ftp://ftp.linux-ipv6.org/pub/usagi/stable/package/turbo/

By the way, we manage the mailing list for USAGI users. If you have 
questions or advices, please join the mailing list. For more ditails, 
please see http://www.linux-ipv6.org/ml/ .

Thanks.

Related Web sites.
	WIDE Project	http://www.wide.ad.jp/
	KAME Project	http://www.kame.net/
	TAHI Project	http://www.tahi.org/

-- 
USAGI Project <http://www.linux-ipv6.org>

From owner-netdev@oss.sgi.com Tue Oct 31 21:43:28 2000
Received:  by oss.sgi.com id <S553924AbQKAFnI>;
	Tue, 31 Oct 2000 21:43:08 -0800
Received: from smtp3.mail.yahoo.com ([128.11.68.135]:20486 "HELO
        smtp1b.mail.yahoo.com") by oss.sgi.com with SMTP id <S553919AbQKAFmm>;
	Tue, 31 Oct 2000 21:42:42 -0800
Received: from ppp037.muskoka.com (HELO gromit.hairy.org) (199.212.175.67)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 1 Nov 2000 05:42:37 -0000
X-Apparently-From: <p?gortmaker@yahoo.com>
Message-ID: <39FFAA94.4D389E85@yahoo.com>
Date:   Wed, 01 Nov 2000 00:31:00 -0500
From:   Paul Gortmaker <p_gortmaker@yahoo.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.17 i486)
MIME-Version: 1.0
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
CC:     pavel rabel <pavel@web.sajt.cz>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.21.0010300344130.6792-100000@web.sajt.cz> <39FC83CD.B10BF08D@mandrakesoft.com> <39FD3CB6.2F641BBF@yahoo.com> <39FDCC17.4C8B8074@mandrakesoft.com>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Jeff Garzik wrote:
> 
> Paul Gortmaker wrote:
> > There is no urgency in trying to squeeze a patch like this in the back
> > door of a 2.4.0 release.  For example, there are people out there now
> > who are using the ne.c driver to run both ISA and PCI cards in the same
> > box without having to use 2 different drivers.  We can wait until 2.5.0
> > to break their .config file.
> 
> IMNSHO this is a bug, though...

Maybe I wasn't 100% clear - these are people who have intentionally
chosen to do so. (There is probably a slight icache benefit in sharing
the same driver like this, FWIW....)

> Since ne2k-pci.c supports all boards ne.c does, and includes some fixes
> that ne.c does not, it seems like removing the PCI support in ne.c is a
> bug fix change.

If you want to roll it into the merge (and can get it past Linus) then
please feel free to do so - I'll be glad to cross it off my list sooner
as opposed to later.

In addition to removing all remains of PCI support from ne.c this patch
also has three trivial changes that were also in my queue for ne.c.

	1) Two new ID signatures added to the bad_clone_list

	2) int base_addr promoted to unsigned int base_addr in ne_probe,
	   as required for SuperH CPU systems that have ne2000 cards.

	3) ISA PnP card info printk'd *before* the actual probe, and
	   not after (just in case the probe silently hangs or whatever).

Paul.

--- 2400-t10/linux-g/drivers/net/ne.c~	Tue Jul 11 02:29:10 2000
+++ 2400-t10/linux-g/drivers/net/ne.c	Wed Nov  1 00:02:17 2000
@@ -29,6 +29,7 @@
     occur after memory is allocated for dev->priv. Deallocated memory
     last in cleanup_modue()
     Richard Guenther    : Added support for ISAPnP cards
+    Paul Gortmaker	: Discontinued PCI support - use ne2k-pci.c instead.
     
 */
 
@@ -43,7 +44,6 @@
 #include <linux/kernel.h>
 #include <linux/sched.h>
 #include <linux/errno.h>
-#include <linux/pci.h>
 #include <linux/isapnp.h>
 #include <linux/init.h>
 #include <linux/delay.h>
@@ -75,23 +75,6 @@
 };
 #endif
 
-#ifdef CONFIG_PCI
-/* Ack! People are making PCI ne2000 clones! Oh the horror, the horror... */
-static struct { unsigned short vendor, dev_id; char *name; }
-pci_clone_list[] __initdata = {
-	{PCI_VENDOR_ID_REALTEK,		PCI_DEVICE_ID_REALTEK_8029,		"Realtek 8029" },
-	{PCI_VENDOR_ID_WINBOND2,	PCI_DEVICE_ID_WINBOND2_89C940,		"Winbond 89C940" },
-	{PCI_VENDOR_ID_COMPEX,		PCI_DEVICE_ID_COMPEX_RL2000,		"Compex ReadyLink 2000" },
-	{PCI_VENDOR_ID_KTI,		PCI_DEVICE_ID_KTI_ET32P2,		"KTI ET32P2" },
-	{PCI_VENDOR_ID_NETVIN,		PCI_DEVICE_ID_NETVIN_NV5000SC,		"NetVin NV5000" },
-	{PCI_VENDOR_ID_VIA,		PCI_DEVICE_ID_VIA_82C926,		"VIA 82C926 Amazon" },
-	{PCI_VENDOR_ID_SURECOM,		PCI_DEVICE_ID_SURECOM_NE34,		"SureCom NE34"},
-	{0,}
-};
-
-static int probe_pci = 1;
-#endif
-
 static struct { unsigned short vendor, function; char *name; }
 isapnp_clone_list[] __initdata = {
 	{ISAPNP_VENDOR('E','D','I'), ISAPNP_FUNCTION(0x0216),		"NN NE2000" },
@@ -114,7 +97,9 @@
     {"ET-100","ET-200", {0x00, 0x45, 0x54}}, /* YANG and YA clone */
     {"COMPEX","COMPEX16",{0x00,0x80,0x48}}, /* Broken ISA Compex cards */
     {"E-LAN100", "E-LAN200", {0x00, 0x00, 0x5d}}, /* Broken ne1000 clones */
-    {"PCM-4823", "PCM-4823", {0x00, 0xc0, 0x6c}}, /* Broken Advantech MoBo */    
+    {"PCM-4823", "PCM-4823", {0x00, 0xc0, 0x6c}}, /* Broken Advantech MoBo */
+    {"REALTEK", "RTL8019", {0x00, 0x00, 0xe8}}, /* no-name with Realtek chip */
+    {"LCS-8834", "LCS-8836", {0x04, 0x04, 0x37}}, /* ShinyNet (SET) */
     {0,}
 };
 #endif
@@ -132,15 +117,9 @@
 #define NESM_START_PG	0x40	/* First page of TX buffer */
 #define NESM_STOP_PG	0x80	/* Last page +1 of RX ring */
 
-/* Non-zero only if the current card is a PCI with BIOS-set IRQ. */
-static unsigned int pci_irq_line = 0;
-
 int ne_probe(struct net_device *dev);
 static int ne_probe1(struct net_device *dev, int ioaddr);
 static int ne_probe_isapnp(struct net_device *dev);
-#ifdef CONFIG_PCI
-static int ne_probe_pci(struct net_device *dev);
-#endif
 
 static int ne_open(struct net_device *dev);
 static int ne_close(struct net_device *dev);
@@ -180,16 +159,9 @@
 {"ne", ne_probe1, NE_IO_EXTENT, netcard_portlist};
 #else
 
-/*
- * Note that at boot, this probe only picks up one card at a time, even for
- * multiple PCI ne2k cards. Use "ether=0,0,eth1" if you have a second PCI
- * ne2k card.  This keeps things consistent regardless of the bus type of
- * the card.
- */
-
 int __init ne_probe(struct net_device *dev)
 {
-	int base_addr = dev ? dev->base_addr : 0;
+	unsigned int base_addr = dev ? dev->base_addr : 0;
 
 	/* First check any supplied i/o locations. User knows best. <cough> */
 	if (base_addr > 0x1ff)	/* Check a single specified location. */
@@ -197,12 +169,6 @@
 	else if (base_addr != 0)	/* Don't probe at all. */
 		return -ENXIO;
 
-#ifdef CONFIG_PCI
-	/* Then look for any installed PCI clones */
-	if (probe_pci && pci_present() && (ne_probe_pci(dev) == 0))
-		return 0;
-#endif
-
 	/* Then look for any installed ISAPnP clones */
 	if (isapnp_present() && (ne_probe_isapnp(dev) == 0))
 		return 0;
@@ -222,43 +188,6 @@
 }
 #endif
 
-#ifdef CONFIG_PCI
-static int __init ne_probe_pci(struct net_device *dev)
-{
-	int i;
-
-	for (i = 0; pci_clone_list[i].vendor != 0; i++) {
-		struct pci_dev *pdev = NULL;
-		unsigned int pci_ioaddr = 0;
-
-		while ((pdev = pci_find_device(pci_clone_list[i].vendor, pci_clone_list[i].dev_id, pdev))) {
-			if (pci_enable_device(pdev))
-				continue;
-			pci_ioaddr = pci_resource_start (pdev, 0);
-			/* Avoid already found cards from previous calls */
-			if (check_region(pci_ioaddr, NE_IO_EXTENT))
-				continue;
-			pci_irq_line = pdev->irq;
-			if (pci_irq_line) break;	/* Found it */
-		}
-		if (!pdev)
-			continue;
-		printk(KERN_INFO "ne.c: PCI BIOS reports %s at i/o %#x, irq %d.\n",
-				pci_clone_list[i].name,
-				pci_ioaddr, pci_irq_line);
-		printk("*\n* Use of the PCI-NE2000 driver with this card is recommended!\n*\n");
-		if (ne_probe1(dev, pci_ioaddr) != 0) {	/* Shouldn't happen. */
-			printk(KERN_ERR "ne.c: Probe of PCI card at %#x failed.\n", pci_ioaddr);
-			pci_irq_line = 0;
-			return -ENXIO;
-		}
-		pci_irq_line = 0;
-		return 0;
-	}
-	return -ENODEV;
-}
-#endif  /* CONFIG_PCI */
-
 static int __init ne_probe_isapnp(struct net_device *dev)
 {
 	int i;
@@ -275,14 +204,18 @@
 				continue;
 			if (idev->activate(idev))
 				continue;
-			pci_irq_line = idev->irq_resource[0].start;
 			/* if no irq, search for next */
-			if (!pci_irq_line)
+			if (idev->irq_resource[0].start == 0)
 				continue;
 			/* found it */
-			if (ne_probe1(dev, idev->resource[0].start) != 0) {	/* Shouldn't happen. */
-				printk(KERN_ERR "ne.c: Probe of ISAPnP card at %#lx failed.\n",
-				       idev->resource[0].start);
+			dev->base_addr = idev->resource[0].start;
+			dev->irq = idev->irq_resource[0].start;
+			printk(KERN_INFO "ne.c: ISAPnP reports %s at i/o %#lx, irq %d.\n",
+				isapnp_clone_list[i].name,
+				
+				dev->base_addr, dev->irq);
+			if (ne_probe1(dev, dev->base_addr) != 0) {	/* Shouldn't happen. */
+				printk(KERN_ERR "ne.c: Probe of ISAPnP card at %#lx failed.\n", dev->base_addr);
 				return -ENXIO;
 			}
 			ei_status.priv = (unsigned long)idev;
@@ -290,9 +223,6 @@
 		}
 		if (!idev)
 			continue;
-		printk(KERN_INFO "ne.c: ISAPnP reports %s at i/o %#lx, irq %d.\n",
-				isapnp_clone_list[i].name,
-				dev->base_addr, dev->irq);
 		return 0;
 	}
 
@@ -403,20 +333,10 @@
 			wordlength = 1;
 	}
 
-	/* At this point, wordlength *only* tells us if the SA_prom is doubled
-	   up or not because some broken PCI cards don't respect the byte-wide
-	   request in program_seq above, and hence don't have doubled up values.
-	   These broken cards would otherwise be detected as an ne1000.  */
-
-	if (wordlength == 2)
-		for (i = 0; i < 16; i++)
-			SA_prom[i] = SA_prom[i+i];
-
-	if (pci_irq_line || ioaddr >= 0x400)
-		wordlength = 2;		/* Catch broken PCI cards mentioned above. */
-
 	if (wordlength == 2) 
 	{
+		for (i = 0; i < 16; i++)
+			SA_prom[i] = SA_prom[i+i];
 		/* We must set the 8390 for word mode. */
 		outb_p(0x49, ioaddr + EN0_DCFG);
 		start_page = NESM_START_PG;
@@ -473,9 +393,6 @@
 #endif
 	}
 
-	if (pci_irq_line)
-		dev->irq = pci_irq_line;
-
 	if (dev->irq < 2) 
 	{
 		autoirq_setup(0);
@@ -509,8 +426,7 @@
 	   share and the board will usually be enabled. */
 
 	{
-		int irqval = request_irq(dev->irq, ei_interrupt,
-				 pci_irq_line ? SA_SHIRQ : 0, name, dev);
+		int irqval = request_irq(dev->irq, ei_interrupt, 0, name, dev);
 		if (irqval) {
 			printk (" unable to get IRQ %d (irqval=%d).\n", dev->irq, irqval);
 			kfree(dev->priv);
@@ -823,10 +739,6 @@
 MODULE_PARM(irq, "1-" __MODULE_STRING(MAX_NE_CARDS) "i");
 MODULE_PARM(bad, "1-" __MODULE_STRING(MAX_NE_CARDS) "i");
 
-#ifdef CONFIG_PCI
-MODULE_PARM(probe_pci, "i");
-#endif
-
 /* This is set up so that no ISA autoprobe takes place. We can't guarantee
 that the ne2k probe is the last 8390 based probe to take place (as it
 is at boot) and so the probe will get confused by any other 8390 cards.
@@ -855,7 +767,7 @@
 		if (io[this_dev] != 0)
 			printk(KERN_WARNING "ne.c: No NE*000 card found at i/o = %#x\n", io[this_dev]);
 		else
-			printk(KERN_NOTICE "ne.c: No PCI cards found. Use \"io=0xNNN\" value(s) for ISA cards.\n");
+			printk(KERN_NOTICE "ne.c: You must supply \"io=0xNNN\" value(s) for ISA cards.\n");
 		unload_8390_module();
 		return -ENXIO;
 	}



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com